Project Compliance Framework
This framework defines how anDREa B.V. (anDREa) programmatically integrates information security, data privacy, and cybersecurity compliance directly into its project management lifecycle. Designed around a risk-proportional "Comply-or-Explain" governance model, this policy bridges agile operational velocity with structured phase-gate oversight.
This framework ensures that all internal features and external client deployments systematically satisfy ISO/IEC 27001:2023 and NIS 2 Directive (Article 21) mandates before moving to a production state.
1. Systemic ISMS & Regulatory Alignment
To ensure a unified compliance posture, every managed project must map its operational parameters to anDREa’s primary Information Security Management System (ISMS) policy layer:
- Information Security Policy (A.05.01 / NIS 2 Art 21(1)): Establishes the foundational mandate that information security risks must be identified, evaluated, and mitigated from project initiation through formal decommissioning.
- Project Management Methodology (A.05.08NIS 2 Art 21(2)(e)): Standardizes contractual requirements—such as Data Processing Agreements (DPAs) and service level metrics—for projects introducing third-party or sub-processor elements.
- Supplier & Customer Security Policy (A.05.19, A.05.20, A.05.21, A.05.22 / NIS 2 Art 21(2)(e)): Standardizes contractual requirements—such as Data Processing Agreements (DPAs) and service level metrics—for projects introducing third-party or sub-processor elements.
- Risk Management Framework (A.05.07 / NIS 2 Art 21(2)(a)): Mandates that project-specific risk registers must feed back directly into the centralized corporate Issues and Risk Logging.
- Asset Management & Classification Policy (A.05.09 / NIS 2 Art 21(2)(g)): Dictates that all software codebases, data environments, and user entitlement matrices produced during a project lifecycle are formally classified and cataloged within the corporate asset inventory.
2. Project Path Classification Matrix
To remain agile while preserving security integrity, anDREa separates workloads using a dual-path classification matrix. Project Managers compile points during the initial setup phase to dictate the mandatory compliance path:
Project Compliance Score = Budget Score + Funding Score + Sign-Off Score + Management Score
- Financial Boundary: Does the projected project budget exceed €10,000? (Budget Score: Yes = +2 points / No = 0 points)
- Commercial Boundary: Are the deliverables directly funded by an external customer or enterprise Tenant? (Funding Score: Yes = +2 points / No = 0 points)
- Acceptance Boundary: Do project outputs require formal legal acceptance or technical sign-off from an external party? (Sign-Off Score: Yes = +2 points / No = 0 points)
- Governance Boundary: Does the project complexity require top management to actively monitor and steer the work? (Management Score: Yes = +2 points / No = 0 points)
Path Thresholds
- Score 0: Excluded from formal project pathways; managed via standard operational changes.
- Score 1 – 5: LIGHT PATH. Applies to low-risk, internal, or maintenance changes. Requires a lightweight, accelerated compliance footprint.
- Score 6 – 8: STANDARD / HEAVY PATH. Applies to cross-tenant structural changes, major code updates, or client-facing delivery models. Requires complete, un-exempted compliance documentation.
3. Mandatory Project Onboarding & Phase-Gate Checklist
The "Comply-or-Explain" principle allows Project Managers to bypass specific actions if they are operationally irrelevant, provided a detailed legal and technical justification is permanently documented within the master Project Charter and kept in the Projects Folder.
Architectural Milestone Phase-Gates
[ L ] = Mandatory for Light Path [ H ] = Mandatory for Heavy/Standard Path
| Phase | ID | Milestone / Action Item | Target | Operational Focus & Documents | ISO 27001 | NIS 2 | Comply-or-Explain Allowed? |
|---|---|---|---|---|---|---|---|
| 1. Initiation | 1.1 | Project Path Classification | L / H | Complete the point matrix to assign the governance tier. | 5.8 | Art 21(1) | No |
| 1.2 | Appoint Security & DPO Roles | L / H | Assign dedicated Security (CISO) and Privacy leads to the project board. | 5.3 | Art 21(1) | Yes (Light Path defaults automatically to corporate CISO) | |
| 1.3 | Project Charter Drafting | L / H | Formally compile and baseline the Project Management Charter. | 5.8 | Art 21(2)(a) | No | |
| 1.4 | Security Impact Assessment | L / H | Execute an SIA to catch infrastructure, platform identity, and access vulnerabilities. | 5.7, 5.8 | Art 21(2)(a) | Yes (Light Path may leverage a condensed 5-question SIA format) | |
| 1.5 | Data Privacy Impact Assessment | H | Execute a comprehensive DPIA to mapping risks to data subjects. | 5.8, 8.11 | GDPR Art 35 | Yes (Only if zero PII or patient data is processed or cached) | |
| 1.6 | Data Processing Agreement (DPA) | H | Conclude formal DPAs with external institutions or participating subcontractors. | 5.19, 5.20 | Art 21(2)(e) | Yes (Only if zero external organizations or PII data pools are involved) | |
| 2. Planning | 2.1 | Security Requirements Definition | L / H | Document and hard-code specific technical controls (e.g., RBAC, MFA, Encryption). | 5.8, 8.25 | Art 21(2)(g),(j) | No |
| 2.2 | Threat Modeling Lifecycle | H | Diagram architecture data flows and execute STRIDE security threat modeling. | 5.8, 8.25 | Art 21(2)(a) | Yes (Requires written CISO sign-off and risk acceptance) | |
| 2.3 | Software Supply Chain Review | H | Audit code repositories, open-source packages, and library dependencies. | 5.19, 8.30 | Art 21(2)(e) | Yes (Only if zero third-party packages or assets are introduced) | |
| 3. Execution | 3.1 | Status Metrics Reporting | L / H | Submit progress and security telemetry updates to the ISMS Steering Committee. | 5.35, 5.36 | Art 21(1) | Yes (Light Path metrics may reduce reporting to a quarterly cadence) |
| 3.2 | Secure Code & Config Review | H | Run automated SAST/DAST pipelines and verify security alignments (e.g., OWASP Top 10). | 8.25, 8.28 | Art 21(2)(d) | Yes (Only if the project introduces no code changes or platform refactoring) | |
| 3.3 | Penetration Testing / Vulnerability Scan | H | Launch targeted manual or automated security penetration tests on pre-production environments. | 8.29 | Art 21(2)(d) | Yes (Subject to formal corporate risk acceptance workflows) | |
| 4. Closing | 4.1 | Deliverable & Security Sign-Off | L / H | Final operational hand-over containing security validation and risk registry closure. | 5.8, 5.36 | Art 21(1) | No |
| 4.2 | ISMS Inventory Update | L / H | Formally register new assets, archive engineering logs, and update the master risk index. | 5.9, 5.12 | Art 21(2)(g) | No |
4. Operational Sign-Off Protocol
Before any code deployment or feature moves from pre-production testing to active availability within mydre.org, the final Deliverable & Security Sign-Off (Milestone 4.1) must be physically executed. This step locks the project documentation, archives the technical design blueprints, and transfers ongoing operational tracking over to our standard Logon policy and How to handle incident tickets.