Security-by-Design ICT Project Governance in 2026
The project was on time, until the audit asked one question
The CISO of a fast-growing payment technology company had good news for the board. The new customer onboarding platform was ready for launch. The product team had delivered the mobile experience, engineering had integrated identity verification, legal had signed the cloud and API providers, and operations had rehearsed the go-live plan.
Then the internal auditor asked a simple question:
“Show me where security and privacy were considered at each stage of the project.”
The project room went quiet.
There was a penetration test report, but it happened late. There was a cloud architecture diagram, but no evidence that data flows had been reviewed against GDPR principles. There was a vendor due diligence questionnaire, but it had not been tied to the risk register. There was a change ticket for production deployment, but the approval did not mention impact on critical services, incident reporting, resilience testing, customer notification, or personal data breach escalation. There were sprint notes, but security requirements were scattered across user stories and chat messages.
Nothing was obviously negligent. Everything looked like a busy modern ICT project. But for a financial entity facing DORA, a SaaS provider potentially in scope of NIS2, and a controller or processor under GDPR, the issue was no longer only whether security existed. The issue was whether security-by-design could be proven.
That is the 2026 problem. ICT projects are no longer judged only by delivery speed, cost control, and technical quality. They are judged by governance evidence: risk assessments, design decisions, supplier due diligence, secure development records, change approvals, privacy decisions, testing results, and management oversight.
ISO/IEC 27001:2022 gives organizations a practical management-system spine for solving this problem. It helps CISOs, compliance managers, project sponsors, DPOs, architects, procurement teams, and auditors turn significant ICT projects into defensible security-by-design evidence.
Why ICT project governance is now a regulatory evidence problem
A cloud migration, customer portal, payment platform, CRM implementation, identity provider change, analytics pipeline, API integration, SaaS workflow, low-code application, or managed service transition can all change the risk profile of the organization. In 2026, those changes happen under overlapping obligations.
NIS2 applies broadly to essential and important entities across Annex I and Annex II sectors, including digital infrastructure, managed service providers, managed security service providers, and digital providers. NIS2 Article 20 makes management bodies responsible for approving cybersecurity risk-management measures and overseeing their implementation. NIS2 Article 21 requires appropriate and proportionate technical, operational, and organisational measures for risk management, incident handling, business continuity, supply chain security, secure acquisition, secure development, vulnerability handling, effectiveness assessment, cyber hygiene, cryptography, access control, asset management, and secure communications.
DORA applies to financial entities and focuses on digital operational resilience. DORA Article 5 places responsibility for ICT risk management on the management body. DORA Article 6 requires a sound, comprehensive, and well-documented ICT risk management framework. DORA also covers ICT-related incident reporting, operational resilience testing, ICT business continuity, response and recovery, cyber threat information sharing, ICT third-party risk management, contractual arrangements, and oversight of critical ICT third-party providers.
GDPR adds the accountability layer for personal data. GDPR Article 25 requires data protection by design and by default. Controllers must be able to demonstrate compliance with principles such as lawfulness, fairness, transparency, purpose limitation, data minimisation, storage limitation, integrity, confidentiality, and accountability. Where processing is likely to result in high risk, a Data Protection Impact Assessment under GDPR Article 35 may also be required.
The common thread is evidence. Regulators and auditors do not only ask whether a platform was encrypted, patched, scanned, or tested. They ask whether the organization can show that security, privacy, supplier risk, and resilience were part of decision-making from the beginning.
That is why ISO/IEC 27001:2022 project governance is so powerful. It allows the organization to manage NIS2, DORA, GDPR, NIST CSF 2.0, contractual obligations, and customer assurance through one repeatable ISMS process rather than multiple disconnected checklists.
The ISO 27001 project governance spine
ISO/IEC 27001:2022 is often misunderstood as a certification exercise. For ICT projects, its operational value is broader. It gives a governance spine for business change.
Clauses 4.1 to 4.4 require organizations to understand internal and external issues, interested parties, legal, regulatory and contractual requirements, ISMS scope, interfaces, and dependencies. In project terms, this means the project charter should identify affected services, customers, suppliers, regulations, business processes, personal data, critical operations, and outsourced services.
Clauses 5.1 to 5.3 require leadership commitment, policy alignment, resources, integration into business processes, and assigned responsibilities. This matters because NIS2 and DORA both place cybersecurity and ICT risk under management-body responsibility. A project that changes a critical customer platform cannot rely on an informal security comment in a chat thread. It needs clear accountability.
Clauses 6.1.1 to 6.1.3 require a repeatable risk assessment and treatment process, risk criteria, risk owners, confidentiality, integrity and availability evaluation, risk treatment plans, Statement of Applicability, and residual risk approval. This is where project risk becomes audit evidence.
Clauses 7.1 to 7.5 require resources, competence, awareness, communication, and control of documented information. This is how project records become reliable evidence rather than scattered artifacts.
Clause 8.1 requires operational planning and control, documented information showing processes were carried out as planned, control of planned changes, review of unintended changes, mitigation of adverse effects, and control of externally provided processes, products, or services relevant to the ISMS. Clauses 8.2 and 8.3 require information security risk assessments and treatment at planned intervals or when significant changes occur.
Annex A then connects this management cycle to practical controls. For security-by-design in ICT projects, three ISO/IEC 27001:2022 Annex A controls are central:
| ISO/IEC 27001:2022 control | Control name | Why it matters for ICT projects |
|---|---|---|
| A.5.8 | Information security in project management | Integrates security into all project phases and creates governance evidence before exposure is created |
| A.8.25 | Secure development life cycle | Embeds security requirements, secure design, secure coding, testing, and deployment discipline |
| A.8.32 | Change management | Ensures production changes are planned, risk assessed, tested, approved, monitored, and reviewable |
Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap treats information security in project management as a governance concern across all project types, not only software development:
“Any project, a marketing system migration, a building relocation, a business process redesign, an HR onboarding platform, even a merger or acquisition, can impact the confidentiality, integrity, or availability of information. And when it does, security must have a seat at the table.”
The same section captures the core implementation lesson:
“The goal of this control isn’t to weigh down projects with red tape. It’s to ensure that security is treated as a design input, not a testing phase.”
That distinction separates compliance theater from defensible security-by-design.
What security-by-design looks like inside an ICT project
Security-by-design starts before the first sprint, procurement request, architecture diagram, or migration runbook. It asks a simple question: what could this project change about risk?
A practical project governance model uses seven evidence gates.
| Project gate | Security-by-design evidence | Typical owner | Cross-compliance value |
|---|---|---|---|
| Initiation | Project security classification, affected services, regulatory applicability, data categories, criticality | Project sponsor and CISO | Supports ISO scope, NIS2 risk measures, DORA critical function analysis, GDPR accountability |
| Requirements | Security requirements, privacy requirements, resilience requirements, supplier requirements | Product owner, security lead, DPO, procurement | Supports secure acquisition, privacy by design, third-party clauses |
| Design | Architecture review, threat model, data-flow map, trust boundaries, cryptography decisions | Architecture and security teams | Supports secure development, GDPR data protection, DORA ICT risk controls |
| Build or configuration | Secure coding records, component inventory, dependency risk, configuration baselines | Engineering or platform team | Supports vulnerability handling, software supply chain security |
| Test | Security test results, abuse cases, vulnerability scans, backup and recovery tests where relevant | QA, security, operations | Supports DORA testing, NIS2 effectiveness assessment, ISO evidence |
| Change approval | Risk acceptance, rollback plan, monitoring plan, incident escalation updates | CAB or delegated approvers | Supports ISO change control, DORA governance reporting, operational resilience |
| Post-implementation | Lessons learned, residual risk review, supplier monitoring, control effectiveness review | Service owner and ISMS manager | Supports continual improvement and audit readiness |
The point is not bureaucracy. The point is to make security visible where project decisions actually happen.
The Clarysec Enterprise Information Security Policy expresses this directly:
“Security governance shall be integrated with enterprise governance, project management, procurement, and legal oversight functions to ensure information security is not siloed but embedded throughout business decision-making.”
From section “Governance Requirements”, policy clause 5.5.
It also makes project lifecycles an implementation concern:
“Project lifecycles (e.g., secure development, threat modeling)”
From section “Policy Implementation Requirements”, policy clause 6.3.1.1.
And it states the audit principle that many organizations discover too late:
“All implemented controls shall be auditable, supported by documented procedures and retained evidence of operation.”
From section “Policy Implementation Requirements”, policy clause 6.6.1.
In other words, security work that is not governed, retained, and mapped will often fail the audit even if technical teams made reasonable decisions.
From threat modeling to evidence: a practical fintech example
Consider a project to launch a new EU customer onboarding portal for a fintech. The portal collects identity documents, performs biometric verification through a third party, stores onboarding status, integrates with CRM, triggers customer notifications, and feeds risk scoring.
A security-by-design approach would build the evidence as the project moves.
First, open a project security classification record. Identify whether the project affects critical or important functions, personal data, special categories of personal data, authentication, customer-facing availability, outsourced ICT services, regulated reporting processes, or customer communications. Under GDPR, biometric data used for unique identification is a special category of personal data unless a specific exception applies. That immediately raises the required level of legal analysis and safeguards.
Second, create a project risk assessment. The Clarysec SME Risk Management Policy makes risk management part of planning, not a quarterly spreadsheet exercise:
“1.2 It ensures that risk management is an active component of planning, project execution, supplier selection, and incident response, in alignment with ISO 27001, ISO 31000, and applicable regulatory requirements.”
From section “Purpose”, policy clause 1.2.
For enterprise environments, the Clarysec Enterprise Risk Management Policy defines scope across project and technical levels:
“It covers information security risks at the strategic, operational, project, and technical levels and is mandatory for all personnel, contractors, and service providers engaged in Information Security Management System (ISMS) activities.”
From section “Scope”, policy clause 2.3.
Third, run a threat model before development begins. The Enterprise Secure Development Policy is explicit:
“All new applications and major changes must undergo secure architecture review and threat modeling before development begins.”
From section “Policy Implementation Requirements”, policy clause 6.1.1.
For the onboarding portal, the threat model should cover exposed interfaces, identity flows, privilege boundaries, API abuse cases, webhook spoofing, replay attacks, compromised credentials, data leakage paths, dependency risk, logging requirements, backup assumptions, recovery requirements, and provider failure modes.
Fourth, update the privacy evidence. The SME Data Protection and Privacy Policy sets the baseline:
“5.3.1. Privacy by design and by default must be enforced in all new systems and services”
From section “Governance Requirements”, policy clause 5.3.1.
The project record should include purpose, lawful basis, controller or processor role, data minimisation decisions, retention rules, access roles, encryption choices, data subject impact considerations, transparency requirements, processor terms, and personal data breach notification paths.
Fifth, record secure development evidence. The SME Secure Development Policy gives a concise evidence list that works for small and mid-sized teams:
“5.3 The General Manager (GM) must maintain records of: 5.3.1 All active software development projects and the responsible developers or vendors 5.3.2 Security checklists used for each project 5.3.3 Code reviews performed and the individuals who performed them 5.3.4 Testing results prior to deployment 5.3.5 Third-party components and their associated licensing or risk status”
From section “Governance Requirements”, policy clause 5.3.
Sixth, control deployment as a change. The SME Change Management Policy states:
“1.1 This policy ensures that all changes to IT systems, configurations, business applications, or cloud services are planned, risk assessed, tested, and approved before implementation.”
From section “Purpose”, policy clause 1.1.
For the onboarding portal, the change ticket should include affected services, risk assessment, test results, rollback plan, monitoring plan, security approvals, privacy sign-off, supplier readiness, incident escalation updates, and customer communication triggers.
Finally, map obligations. The SME Legal and Regulatory Compliance Policy provides the operating rule:
“5.2.2 Where a regulation applies across multiple areas (e.g., GDPR applies to retention, security and privacy), this must be clearly mapped in the Compliance Register and training materials.”
From section “Governance Requirements”, policy clause 5.2.2.
That Compliance Register becomes the bridge between ISO/IEC 27001:2022 controls, NIS2 Article 21 measures, DORA ICT risk obligations, GDPR accountability, and customer contract commitments.
Mapping one project evidence pack to NIS2, DORA, GDPR and NIST CSF 2.0
The most efficient compliance strategy is not to duplicate work. It is to map one strong evidence set to multiple obligations.
The Zenith Blueprint, in the Risk Management phase, Step 14, recommends this kind of cross-reference work:
“For each regulation, if applicable, you may create a simple mapping table (could be an appendix in a report) that lists the regulation’s key security requirements and the corresponding controls/policies in your ISMS.”
It adds that this is useful because it shows auditors and assessors “that you’re not managing security in a vacuum but aware of legal context.”
Clarysec’s Zenith Controls: The Cross-Compliance Guide supports the same integrated approach by mapping ISO/IEC 27001:2022 controls to other frameworks, audit expectations, and compliance needs. For ICT project governance, it frames A.5.8, A.8.25, and A.8.32 as preventive controls that protect confidentiality, integrity, and availability across governance, application security, ecosystem, protection, and system and network security concerns.
| Evidence artifact | ISO/IEC 27001:2022 purpose | NIS2 value | DORA value | GDPR value |
|---|---|---|---|---|
| Project security classification | Defines scope, interested parties, dependencies and operational control | Shows risk-based identification of affected systems and services | Identifies critical or important function impact | Identifies personal data, roles and processing context |
| Threat model | Supports risk assessment and secure development controls | Supports secure acquisition, development and vulnerability handling | Supports ICT risk framework and resilience strategy | Supports privacy by design and appropriate safeguards |
| Supplier due diligence and contract review | Supports supplier and ICT supply chain controls | Supports supply chain security and direct supplier assessment | Supports ICT third-party risk, audit rights, exit planning | Supports processor safeguards and processing instructions |
| Secure development and test records | Supports secure SDLC, vulnerability management and change readiness | Supports secure development and effectiveness assessment | Supports resilience testing and remediation | Supports security of processing and breach risk reduction |
| Change approval record | Supports planned changes, review and mitigation of adverse effects | Supports risk-managed implementation | Supports governance reporting and operational resilience | Supports accountability for system changes affecting personal data |
| Incident and monitoring update | Supports logging, monitoring, incident planning and evidence collection | Supports incident handling and reporting readiness | Supports major ICT incident classification and escalation | Supports personal data breach detection and response |
| Compliance Register mapping | Supports legal and regulatory requirements and documented information | Demonstrates Article 21 alignment | Demonstrates DORA framework integration | Demonstrates accountability across principles |
This table is not a substitute for legal analysis. It is a governance accelerator. It ensures the CISO, DPO, project sponsor, procurement lead, system owner, and internal auditor are looking at the same evidence.
NIST CSF 2.0 also fits naturally into this model. Its GOVERN Function helps organizations establish policies, roles, risk appetite, oversight, and legal or contractual awareness. Its IDENTIFY, PROTECT, DETECT, RESPOND, and RECOVER Functions help teams discuss assets, supplier services, access control, data security, platform security, secure software development, monitoring, incident response, and recovery in a shared operating language.
| Regulatory or framework requirement | How ISO 27001 project governance provides evidence |
|---|---|
| DORA Article 5, Governance and organisation | Shows management oversight, defined responsibilities, escalation paths, and approval of ICT risk decisions |
| DORA Article 6, ICT risk management framework | Produces project-level ICT risk assessments, treatment records, resilience requirements, and control evidence |
| DORA Article 28, ICT third-party risk | Documents supplier due diligence, contractual safeguards, audit rights, exit planning, and ongoing monitoring |
| NIS2 Article 20, Governance | Shows management approval and oversight of cybersecurity risk-management measures |
| NIS2 Article 21(2)(d), Supply chain security | Records supplier assessment, procurement criteria, service provider risks, and contractual security requirements |
| NIS2 Article 21(2)(e), Secure acquisition, development and maintenance | Captures secure requirements, architecture review, vulnerability handling, testing, and remediation evidence |
| GDPR Article 25, Data protection by design and by default | Shows privacy requirements, minimisation, retention, access control, processor safeguards, and DPIA outcomes where required |
| NIST CSF 2.0 GV.PO-01 and GV.PO-02 | Demonstrates that cybersecurity policies are established, communicated, enforced, reviewed, and updated through project execution |
A single ISO 27001-aligned process centered on Annex A.5.8 can generate defensible evidence for all of these expectations.
Secure development is broader than writing code
Many ICT project failures happen because the organization treats secure development as something only developers do. In 2026, secure development also includes SaaS configuration, workflow automation, infrastructure as code, API integrations, identity rules, cloud landing zones, analytics pipelines, robotic process automation, and low-code business applications.
The Zenith Blueprint, Controls in Action phase, Step 20, addresses ISO/IEC 27002:2022 control 8.25 Secure Development Life Cycle:
“This control applies whether you’re writing your own applications, configuring platforms like ERP or CRM systems, customizing SaaS workflows, or managing infrastructure-as-code environments.”
It also explains that security requirements must sit alongside functional requirements, and that threat modeling helps identify exposed parts of the system, risky user roles, and data flows requiring higher protection.
For a modern project, secure development evidence may include:
- Security requirements linked to business requirements
- Threat model or secure architecture review
- Secure coding or secure configuration checklist
- Code review or peer review records
- Component inventory and dependency risk status
- Secrets management decisions
- Access control and least privilege design
- Logging and monitoring requirements
- Vulnerability scan results and remediation records
- Pre-production security testing
- Backup, recovery, and resilience testing where relevant
- Deployment approval and rollback evidence
The goal is not to force every project through the same heavyweight process. The goal is proportionality. A minor internal workflow change does not require the same evidence as a core payment platform migration. But every project should be classified, risk assessed, and governed according to impact.
Change management protects the project from itself
The riskiest moment in many projects is not design or coding. It is deployment.
A team can perform threat modeling, code review, supplier assessment, and privacy review, then still create an outage or breach through a rushed production change. A debug flag remains enabled. A firewall rule is broader than approved. A migration script copies personal data to a non-production environment. A third-party webhook endpoint is deployed without authentication. A logging change records identity document numbers. A backup job fails silently after the cutover.
The Zenith Blueprint, Controls in Action phase, Step 21, describes ISO/IEC 27002:2022 control 8.32 Change Management in direct terms:
“Change is inevitable, but in cybersecurity, uncontrolled change is dangerous.”
It continues:
“At its core, effective change management is a repeatable workflow. It begins with a clear proposal, outlining what’s changing, why, when, and what the potential risks are.”
A strong ICT change record should answer:
- What system, service, data flow, supplier or configuration is changing?
- Which risks were identified and who owns them?
- Does the change affect personal data, critical services, authentication, logging, backups or incident response?
- What security, privacy, resilience, and supplier checks were performed?
- What tests were completed before deployment?
- What monitoring will confirm expected behavior?
- What rollback or recovery plan exists?
- Who approved residual risk?
- What evidence will be retained?
For DORA, this supports documented ICT risk management, resilience, continuity, incident classification, and lessons learned. For NIS2, it supports risk-management measures, secure development, incident prevention, and continuity. For GDPR, it helps demonstrate that changes affecting personal data were reviewed against purpose, minimisation, retention, access, and security principles.
Supplier and cloud decisions must be part of project design
In modern ICT projects, the highest-risk design decision is often “buy” rather than “build.” Cloud services, API providers, identity verification platforms, payment processors, analytics vendors, managed service providers, and managed security providers become part of the risk surface.
NIS2 explicitly includes supply chain security, direct supplier and service provider vulnerabilities, supplier cybersecurity practices, secure development procedures, and coordinated supply-chain risk assessment results. DORA goes deeper for financial entities. It requires ICT third-party risk management as part of the ICT risk management framework, continuing responsibility even when ICT services are outsourced, information registers, pre-contract assessments, concentration-risk analysis, contract controls, audit and inspection rights, termination triggers, and tested exit strategies for critical or important functions.
For the onboarding portal, the biometric verification provider cannot be approved only because procurement likes the price and the API documentation is good. The project needs evidence of security due diligence, processing role, data location, subcontractors, availability commitments, incident support, audit rights, termination assistance, exit feasibility, and monitoring obligations.
In a mature evidence model, supplier and cloud decisions sit inside the project evidence pack, not in a disconnected vendor folder. When the auditor asks why a third party was accepted, the answer should include business need, risk assessment, contract safeguards, data protection review, resilience impact, and ongoing monitoring.
How auditors will review security-by-design evidence
Different auditors approach the same ICT project from different angles. A certification auditor, internal auditor, DORA reviewer, NIS2 competent authority, privacy auditor, NIST-oriented assessor, or COBIT-style auditor may ask for similar evidence but interpret it differently.
| Audit lens | What the auditor will ask | Evidence that usually satisfies the question |
|---|---|---|
| ISO/IEC 27001:2022 auditor | Was information security integrated into project management and operational planning, and are risk treatment decisions documented? | Project charter, risk assessment, SoA mapping, treatment plan, stage-gate approvals, documented information controls |
| NIST CSF 2.0 assessor | Are governance, risk, supplier, protect, detect, respond and recover outcomes reflected in project decisions? | Current and Target Profile, gap plan, supplier inventory, access design, monitoring plan, incident and recovery procedures |
| COBIT or ISACA-style auditor | Are objectives, ownership, process controls, decision rights and performance monitoring clear? | RACI, governance minutes, control ownership, KPI and KRI reports, change approvals, internal audit findings |
| DORA reviewer | Does the project affect critical or important functions, ICT third-party dependencies, resilience testing or incident reporting? | Criticality assessment, ICT risk record, supplier register, contract clauses, test results, incident classification updates |
| GDPR or privacy auditor | Did the project apply privacy by design, lawful basis, minimisation, retention, security and accountability? | Data-flow map, lawful-basis record, DPIA where appropriate, access matrix, retention rules, processor terms, breach playbook updates |
Auditors do not want a beautiful project slide deck. They want traceability. They want to see that requirements led to risks, risks led to controls, controls led to implementation evidence, and implementation led to review.
That is why Zenith Controls is useful in audit preparation. It helps teams explain why Annex A.5.8, A.8.25, and A.8.32 are preventive controls that protect confidentiality, integrity, and availability before predictable failures reach production.
The minimum Clarysec project evidence pack
A strong security-by-design evidence pack does not need to be enormous. It needs to be consistent, proportional, and mapped.
For a medium-risk ICT project, Clarysec typically recommends the following minimum pack:
- Project security classification record
- Regulatory applicability note covering NIS2, DORA where relevant, GDPR and contractual obligations
- Data-flow and asset impact map
- Project risk assessment and treatment plan
- Threat model or secure architecture review
- Supplier and cloud service assessment where applicable
- Secure development checklist or configuration checklist
- Security test results and remediation evidence
- Change approval with rollback and monitoring plan
- Privacy-by-design record, including lawful basis and retention where personal data is involved
- Incident response and monitoring updates
- Post-implementation review and lessons learned
- Compliance Register mapping to controls and obligations
The Zenith Blueprint gives the roadmap logic. Step 22 brings information security into all project stages. Step 20 embeds secure development into planning, design, code, testing, and deployment. Step 21 makes change management structured, traceable, and reviewable. Step 14 recommends cross-referencing GDPR, NIS2, DORA, and other obligations so compliance requirements do not fall through the cracks.
The policies give operating rules. Information Security Policy integrates security with project management, procurement, and legal oversight. Risk Management Policy makes project risks part of ISMS activity. Secure Development Policy requires threat modeling. Change Management Policy requires planned, risk-assessed, tested, and approved changes. Data Protection and Privacy Policy requires privacy by design and by default. Legal and Regulatory Compliance Policy requires multi-area regulations to be mapped in the Compliance Register.
Together, these tools turn security-by-design from an aspiration into an auditable operating model.
Common failure patterns in ICT projects
The failures are usually predictable.
The first is late security involvement. Security reviews happen after the architecture is fixed, contracts are signed, and delivery dates are public. At that point, security becomes a blocker rather than a design input.
The second is fragmented evidence. The project has test results in one tool, supplier review in another, privacy comments in email, risk acceptance in a meeting recording, and change approval in a ticket. No single thread proves governance.
The third is supplier blind spots. The project relies on a cloud service or API provider, but no one checks subcontractors, data location, audit rights, incident support, exit plans, or concentration risk.
The fourth is privacy drift. A system built for one purpose starts supporting analytics, AI experimentation, marketing exports, or operational monitoring without revisiting lawful basis, transparency, minimisation, or retention.
The fifth is unreviewed change. A production deployment is approved for functionality but not assessed for access, logging, encryption, backup, resilience, personal data, or reporting impact.
The sixth is weak management oversight. High-impact project risks are accepted at too low a level, with no evidence that the responsible risk owner understood the regulatory consequences.
These problems are not solved by buying another scanner. They are solved by integrating security governance into the way projects are proposed, designed, procured, built, tested, changed, and reviewed.
The 2026 CISO takeaway
Security-by-design in ICT projects is now a board, audit, and regulatory issue. NIS2 makes cybersecurity risk management a management-body concern. DORA makes ICT risk, resilience testing, incident management, and third-party oversight a structured financial-sector obligation. GDPR requires accountability for personal data processing and appropriate security. ISO/IEC 27001:2022 provides the management-system structure to make these obligations operational.
For CISOs, the opportunity is to stop fighting project teams at the end of delivery. Put security into initiation, requirements, design, supplier selection, build, test, change approval, and post-implementation review.
For compliance managers, the opportunity is to replace scattered evidence with one mapped project evidence pack.
For auditors, the opportunity is to test the project lifecycle, not just the final system.
For business owners, the opportunity is faster and safer delivery. Security-by-design reduces rework, prevents compliance surprises, improves supplier decisions, and gives leadership a defensible risk story.
If your ICT projects are moving faster than your evidence model, start with one pilot project. Use Clarysec’s Zenith Blueprint to define project security gates, apply Clarysec policies for risk management, secure development, change management and privacy, and use Zenith Controls to map ISO/IEC 27001:2022 project governance to NIS2, DORA, GDPR, and NIST CSF 2.0.
Clarysec can help you build a reusable security-by-design project evidence pack, align it with your ISMS, and prepare it for internal audit, certification audit, DORA readiness, NIS2 governance, and GDPR accountability.
Start with your next significant ICT project. If it changes systems, suppliers, data, access, resilience, or customer trust, it deserves security-by-design from day one.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
