CRA 2026 Product Security File with ISO 27001
A connected-device manufacturer calls its CISO, Maria, into a Friday afternoon meeting. Sales has just secured a European distribution agreement. Legal is asking whether the company can support Cyber Resilience Act conformity. Engineering says secure development is “mostly covered” because code review, SAST and patching exist. Procurement says suppliers are “under NDA.” Product teams have firmware dependencies in one tool, cloud API inventories in another, and vulnerability tickets in Jira. Compliance has ISO/IEC 27001:2022 certification evidence, but it is organized around the corporate ISMS, not around each product placed on the EU market.
Then the uncomfortable question lands: “If an EU authority, customer, notified body or major distributor asks for the Product Security File in 2026, can we produce it in one week?”
For many software vendors, smart-device manufacturers and connected-service providers, the honest answer is no. Not because they lack security controls, but because their product security evidence is scattered. Secure development records sit with engineering. SBOMs are generated per build but not governed. Coordinated vulnerability disclosure exists as a web page, but it is not always connected to triage, fixes, advisories and post-market monitoring. Supplier security is buried in procurement contracts. Incident reporting belongs to security operations, while conformity documentation belongs to product compliance.
The EU Cyber Resilience Act changes the operating model. Product cybersecurity is no longer only a best practice or a contractual promise. It becomes a lifecycle evidence obligation. Organizations must be able to show how cybersecurity requirements are built into design, development, release, vulnerability handling, updates and monitoring after the product enters the market.
This is where ISO/IEC 27001:2022 becomes powerful, if used correctly. It is not a product certification scheme by itself, but its ISMS, risk, asset, supplier, secure development, vulnerability and incident controls can provide the backbone of a CRA Product Security File. The goal is not to create another compliance silo. The goal is to convert your existing ISMS into a product-level evidence system.
As Clarysec’s Zenith Blueprint: An Auditor’s 30-Step Roadmap puts it in Phase 2, Step 8, Evidence Architecture:
“Evidence should not be collected at the end of the audit cycle. It should be designed into the control, assigned to an owner, time-stamped by the process, and reusable across every obligation that asks the same question in different language.”
That sentence captures the core of CRA readiness. The question is not just, “Do we have secure development?” The question is, “Can we prove secure development, component awareness, vulnerability handling and post-market monitoring for this product, this version, this release and this market?”
The CRA Product Security File is a living evidence system
A CRA Product Security File should not be treated as a static PDF produced once before release and forgotten. It should be a structured dossier that tells the security story of the product from concept to end of support.
A useful file explains:
- What the product is and how it is intended to be used.
- Which software, firmware, cloud services and third-party dependencies it includes.
- Which cybersecurity risks were assessed.
- Which security requirements were applied.
- How secure development was performed.
- How vulnerabilities are received, triaged, fixed and disclosed.
- How secure updates are delivered.
- How suppliers and open-source components are controlled.
- How incidents and actively exploited vulnerabilities are escalated.
- How the product is monitored after being placed on the market.
For a CISO, this is an ISMS evidence challenge. For a product compliance manager, it is technical documentation. For engineering, it is DevSecOps and release governance. For executives, it is market access and liability control.
The mistake is treating those as separate workstreams. The better model is to build a product-level evidence file that maps to ISO/IEC 27001:2022 and ISO/IEC 27002:2022 controls, then cross-maps the same evidence to NIS2, DORA, GDPR, NIST and COBIT 2019 where relevant.
Clarysec’s Zenith Controls: The Cross-Compliance Guide describes this as a control-to-evidence-to-auditor chain:
“A cross-compliance evidence file should map each obligation to the operating control, the recurring evidence object, the accountable owner, and the audit lens that will be used to challenge it.”
That is the discipline CRA preparation needs. The Product Security File is not merely a folder. It is the translation layer between product engineering, security governance, conformity assessment and customer assurance.
Build the product evidence spine first
The file needs a consistent structure before teams start uploading records. Without a clear spine, evidence becomes a pile of screenshots, exports and policy PDFs that no auditor can follow.
For CRA readiness workshops, Clarysec typically recommends the following Product Security File structure for organizations already operating an ISO/IEC 27001:2022 ISMS.
| Product Security File section | Primary evidence | ISO/IEC 27001:2022 and ISO/IEC 27002:2022 control themes | Typical owner |
|---|---|---|---|
| Product definition and intended use | Product description, architecture, data flow, deployment model | A.5.9 Inventory of information and other associated assets, A.5.8 Information security in project management, risk assessment | Product owner |
| Component and dependency inventory | SBOM, firmware bill of materials, cloud dependency map | A.5.9 Inventory, A.8.9 Configuration management, A.8.8 Management of technical vulnerabilities | Engineering lead |
| Secure development evidence | Threat models, secure design reviews, code review records, security test results | A.8.25 Secure development life cycle, A.8.27 Secure system architecture and engineering principles, A.8.28 Secure coding, A.8.29 Security testing in development and acceptance | Engineering and AppSec |
| Vulnerability handling and CVD | Disclosure policy, intake records, triage logs, fix SLAs, advisory templates | A.8.8 Management of technical vulnerabilities, A.5.24 Information security incident management planning and preparation, A.5.26 Response to information security incidents | Security operations |
| Supplier and open-source evidence | Supplier assessments, contractual clauses, OSS review, component provenance | A.5.19 Information security in supplier relationships, A.5.20 Addressing information security within supplier agreements, A.5.21 Managing information security in the ICT supply chain | Procurement and legal |
| Secure update and release evidence | Release approvals, signing records, rollback plans, patch notes | A.8.32 Change management, A.8.24 Use of cryptography, A.8.9 Configuration management | Release manager |
| Post-market monitoring | Vulnerability feeds, telemetry, customer reports, incident reviews, periodic risk review | A.8.15 Logging, A.8.16 Monitoring activities, A.5.25 Assessment and decision on information security events, continual improvement | CISO and product security |
| Conformity and audit pack | Control mapping, management approval, retained evidence index | ISMS governance, A.5.28 Collection of evidence, internal audit, management review | Compliance manager |
This table does not replace legal technical documentation obligations. It gives the business an operating model for proving them.
In the Zenith Blueprint, Phase 1, Step 3 focuses on scope and boundary definition. For CRA, that step becomes product-specific. Define the product family, software versions, deployment assumptions, user roles, connected services, update channels and support period. If the ISMS scope is “Corporate SaaS and device management platform,” the CRA file must still answer a narrower question: “Which product with digital elements is being placed on the EU market, and what is included in that product?”
Map secure development to product-level records
The heart of the Product Security File is evidence of security-by-design. ISO/IEC 27001:2022 provides the governance system. ISO/IEC 27002:2022 provides implementation guidance through controls such as A.8.25 Secure development life cycle, A.8.27 Secure system architecture and engineering principles, A.8.28 Secure coding and A.8.29 Security testing in development and acceptance.
The important shift is from generic secure development claims to release-specific records. “We perform code review” is not enough. The file should show which release was reviewed, which risks were considered, which security tests passed, which vulnerabilities were accepted or remediated, and who approved the release.
Clarysec’s Enterprise Secure development policy is designed to force that evidence trail. In clause 6.1, Secure Development Lifecycle Requirements, it states:
“Each product or service release shall maintain documented evidence of security requirements, design review, secure coding activities, security testing, vulnerability remediation decisions, and release approval before production deployment.”
This clause is useful for CRA because it turns secure development into a repeatable evidence pattern. An auditor does not need to infer that secure development happened. They can inspect the release record.
For a smart thermostat, medical IoT device, industrial sensor or SaaS-connected product, the secure development evidence should include:
- Product security requirements mapped to identified risks.
- Threat model or abuse-case analysis for the product and connected services.
- Architecture review, including trust boundaries and external interfaces.
- Secure coding standard and proof of developer acknowledgement or training.
- SAST, DAST, software composition analysis, secrets scanning and firmware analysis where applicable.
- Remediation tickets for high-risk findings.
- Risk acceptance records with business and security approval.
- Release gate checklist showing security criteria were met.
- Cryptographic signing and update integrity evidence.
- Support-period and end-of-life assumptions.
Other standards help strengthen the method. ISO/IEC 27005 supports the risk approach behind these records. ISO/IEC 27017 is useful where cloud services form part of the product ecosystem. ISO/IEC 27035 supports incident handling. ISO/IEC 29147 and ISO/IEC 30111 are especially relevant for vulnerability disclosure and vulnerability handling. ISO/IEC 27036 supports supplier security, which matters when the product includes outsourced software, embedded modules, managed cloud services or third-party libraries.
In Zenith Controls, CRA secure development evidence is usually mapped around ISO/IEC 27002:2022 control themes such as information security in project management, secure development life cycle, secure coding, security testing, change management and technical vulnerability management. The guide also ties these to asset inventory and supplier controls, because no secure development process is complete if the organization cannot identify the components it ships.
Treat the SBOM as regulated product evidence
The Software Bill of Materials is often treated as a technical artifact. For CRA readiness, it should be treated as product evidence.
A useful SBOM tells you what components are in the product, which versions are used, where they came from, which licenses apply, which vulnerabilities affect them, and which releases contain them. For firmware and embedded products, this may include operating system packages, bootloaders, libraries, drivers, containers, third-party modules and cloud-side dependencies required for product operation.
The problem is that many organizations generate SBOMs but do not govern them. A build pipeline may produce an SPDX or CycloneDX file, but no one validates completeness. Security tooling may flag vulnerabilities, but the results are not tied to product versions. Procurement may approve a supplier, but that supplier’s component list is not reconciled with the released product.
Clarysec’s Enterprise Asset management policy addresses this governance gap in clause 5.2, Information and Associated Asset Inventory:
“Information assets and associated technology components shall be identified, assigned an owner, classified where applicable, and maintained in an inventory that supports risk assessment, vulnerability management, change control, and audit evidence.”
For CRA, that clause becomes product-specific. The SBOM is part of the inventory of associated technology components. It needs an owner, a retention rule, a validation process and a link to vulnerability management.
A practical SBOM evidence rule is simple: every released product version must have an approved component inventory that can be matched to the release artifact. If the organization cannot connect the SBOM to the exact firmware image, application package, container digest or SaaS release, the SBOM is weak evidence.
| Check | Evidence to collect | Pass criteria |
|---|---|---|
| Release linkage | Release ID, build hash, firmware version, container digest or package ID | SBOM clearly maps to the released artifact |
| Component completeness | SBOM file, dependency scan report, manual exceptions | Direct and transitive dependencies are captured or exceptions are justified |
| Vulnerability status | SCA report, vulnerability tickets, risk acceptances | Known exploitable or high-risk findings have remediation or approved exception |
| Supplier linkage | Supplier component declarations, third-party attestations, support terms | Critical supplied components have supplier evidence |
| License and provenance | License scan, source repository record, approved package source | Component origin and usage are documented |
| Retention and access | Evidence repository path, owner, retention rule | Compliance can retrieve the SBOM and related records within defined time |
If more than two rows fail, the issue is usually not the SBOM tool. It is governance. The Product Security File should record a corrective action in the ISMS, because CRA evidence weakness is also an ISO/IEC 27001:2022 control effectiveness issue.
Connect CVD to vulnerability handling and release governance
Coordinated vulnerability disclosure is one of the most visible CRA readiness areas because external researchers, customers and authorities can test it directly. Publishing a vulnerability disclosure page or security.txt file is useful, but it is only the front door. The Product Security File must prove the back office works.
A defensible CVD and vulnerability handling evidence set should include:
- Public disclosure channel and submission instructions.
- Researcher acknowledgement process.
- Triage criteria, including severity and exploitability assessment.
- Product impact analysis.
- Remediation ownership and target timelines.
- Customer advisory and update communication templates.
- Evidence of secure patch development and testing.
- Records of coordinated publication where applicable.
- Lessons learned and recurring vulnerability trend analysis.
Clarysec’s Enterprise Vulnerability management policy clause 6.3, Vulnerability Intake, Triage and Remediation, states:
“Reported vulnerabilities shall be logged, assessed for affected assets and products, prioritized according to risk and exploitability, assigned to an accountable owner, and tracked through remediation, verification, communication, and closure.”
That clause connects CVD to SBOM, asset inventory, engineering tickets, release management and post-market monitoring. It is also the clause auditors will naturally test: show the intake record, show the affected products, show the triage, show the fix, show customer communication, show closure.
Your existing Information Security Incident Management Policy should also be extended to cover product vulnerabilities that become incidents or require external notification. ISO/IEC 27002:2022 A.5.24 covers incident management planning and preparation, A.5.25 covers assessment and decision on information security events, A.5.26 covers response to information security incidents, and A.5.27 covers learning from incidents.
In Zenith Controls, vulnerability management is treated as both preventive and corrective. The preventive side includes inventory, secure development, supplier monitoring and secure configuration. The corrective side includes detection, triage, patching, communication and incident escalation. This distinction matters because post-market vulnerability handling is part of the product lifecycle obligation, not an afterthought.
Supplier evidence is the hidden weakness
The Product Security File will often be challenged hardest where the manufacturer relies on others. This includes embedded modules, outsourced firmware development, white-label components, cloud hosting, mobile SDKs, payment services, cryptographic libraries and managed support providers.
The common failure pattern is contractual abstraction. The manufacturer says, “Our supplier is responsible for that.” Under product security scrutiny, that is not enough. The organization must show that supplier risk is identified, security requirements are communicated, evidence is collected, vulnerabilities are coordinated and changes are controlled.
Clarysec’s Enterprise Third-party and supplier security policy clause 7.1, Supplier Security Requirements, states:
“Suppliers that develop, operate, process, support, or materially affect information systems, products, or services shall be assessed according to risk and shall be subject to security requirements covering access, vulnerability management, incident notification, subcontracting, continuity, and evidence provision.”
For CRA, the phrase “materially affect products” is critical. If a supplier component can introduce a vulnerability, disrupt updates, expose customer data or compromise device integrity, it belongs in the Product Security File.
The same policy can also support SBOM contracting. Clause 7.3 states:
“For all third-party software components, libraries, or operating systems to be integrated into company ‘Products with Digital Elements,’ the supplier must provide, upon request, a machine-readable Software Bill of Materials (SBOM) in a standard format such as SPDX or CycloneDX. This requirement must be embedded within all procurement and supplier contracts.”
A strong supplier evidence pack should include supplier classification by product impact, security requirements in contracts, supplier secure development evidence for critical components, supplier vulnerability disclosure commitments, SBOM or component declarations where feasible, patch support and end-of-life timelines, periodic review records and escalation paths for supplier-origin vulnerabilities.
ISO/IEC 27002:2022 A.5.19, A.5.20 and A.5.21 provide the key supplier control themes. ISO/IEC 27036 adds depth for supplier relationship security. In cross-compliance terms, NIS2 emphasizes supply chain and vulnerability handling. DORA emphasizes ICT third-party risk for financial entities. GDPR becomes relevant when the product or its cloud services process personal data. COBIT 2019 frames supplier governance as an enterprise technology governance issue, not only a security operations issue.
Post-market monitoring turns evidence into operations
The most mature product security organizations think beyond release. They ask, “How will we know this product has become risky after it is in the field?”
Post-market monitoring should capture signals from vulnerability feeds, exploit intelligence, customer support, telemetry, bug bounty or researcher reports, supplier notifications, cloud logs, incident records and field performance data. It should also include periodic review of product risk when threat conditions change.
Clarysec’s Enterprise Logging and monitoring policy clause 5.4, Security Monitoring and Review, states:
“Security-relevant events shall be collected, reviewed, escalated, and retained in a manner that supports timely detection, investigation, incident response, compliance reporting, and continual improvement.”
For connected products, this must be interpreted carefully. Monitoring must respect privacy, data minimization and legal constraints, especially where telemetry includes personal data or customer operational data. GDPR mapping is important. Product security teams should work with privacy teams to define which telemetry is necessary for security, how it is minimized, how long it is retained and how customers are informed.
Post-market monitoring evidence should include a product security monitoring plan, vulnerability intelligence sources, customer report intake channels, supplier notification channels, telemetry or log review scope, periodic product risk review minutes, patch adoption tracking, incident trend analysis and management review inputs.
In the Zenith Blueprint, Phase 5, Step 30 focuses on continual improvement and surveillance readiness. For CRA, this is where the Product Security File becomes a living file. Each product release, vulnerability, supplier change and field signal should update the evidence record.
One evidence file, many compliance questions
A well-designed CRA Product Security File reduces duplication because the same evidence answers multiple compliance questions. The language changes, but the control reality is often similar.
| Evidence object | CRA relevance | ISO/IEC 27001:2022 and ISO/IEC 27002:2022 theme | NIS2, DORA, GDPR, NIST and COBIT 2019 relevance |
|---|---|---|---|
| Product risk assessment | Shows security risks were considered during product design and lifecycle | Risk assessment, A.5.8 Information security in project management, A.8.25 Secure development life cycle | NIS2 risk management, DORA ICT risk management, NIST Govern and Identify, COBIT risk governance |
| SBOM and component inventory | Shows knowledge of software components and vulnerability exposure | A.5.9 Inventory, A.8.9 Configuration management, A.8.8 Management of technical vulnerabilities | NIS2 supply chain, DORA ICT asset awareness, NIST Asset Management, COBIT managed assets |
| Secure development records | Shows security was built into design and release | A.8.25 Secure development life cycle, A.8.27 Secure architecture, A.8.28 Secure coding, A.8.29 Security testing | NIST Protect, COBIT build and change governance, GDPR security by design where personal data is involved |
| CVD and vulnerability tickets | Shows ability to receive, assess, remediate and communicate vulnerabilities | A.8.8 Management of technical vulnerabilities, A.5.24 Incident planning, A.5.26 Incident response | NIS2 vulnerability handling, DORA incident and vulnerability processes, NIST Respond |
| Supplier evidence | Shows product dependencies are governed | A.5.19 Supplier relationships, A.5.20 Supplier agreements, A.5.21 ICT supply chain | NIS2 supply chain security, DORA ICT third-party risk, COBIT vendor governance |
| Post-market monitoring | Shows ongoing product security surveillance | A.8.15 Logging, A.8.16 Monitoring activities, A.5.25 Event assessment, continual improvement | NIS2 incident detection, DORA monitoring, NIST Detect, GDPR breach detection support |
| Incident reporting records | Shows escalation and notification readiness | A.5.24 Incident planning, A.5.25 Event assessment, A.5.26 Incident response, A.5.27 Learning from incidents | NIS2 and DORA reporting, GDPR breach assessment, NIST Respond and Recover |
Zenith Controls is designed for this reuse. It maps ISO/IEC 27002:2022 control themes to attributes such as preventive, detective and corrective control purpose, cybersecurity concepts, operational capabilities and security properties. For CRA, this helps a CISO explain why a single evidence object, such as a release security review, supports secure development, risk treatment, change control, vulnerability management and audit readiness.
Prepare for different auditor lenses
A CRA Product Security File may be challenged by an ISO auditor, internal audit team, customer assurance team, product conformity reviewer, regulator, NIST-based assessor or ISACA-trained COBIT auditor. Each will ask similar questions through a different lens.
| Auditor lens | What they will ask | Strong evidence |
|---|---|---|
| ISO/IEC 27001:2022 auditor | Is product security governed within the ISMS, risk process, competence model, operational controls and continual improvement cycle? | ISMS scope, risk assessment, Statement of Applicability, secure development records, internal audit findings, management review |
| ISO/IEC 27006-1:2024 certification perspective | Is the audit evidence reliable, sampled appropriately and linked to the certified management system? | Evidence index, sampling logic, owner interviews, retained records, corrective action tracking |
| NIST-oriented assessor | Can you show governance, asset identification, protection measures, detection, response and recovery for the product lifecycle? | Product risk register, SBOM, monitoring plan, vulnerability workflow, incident playbooks |
| COBIT 2019 or ISACA auditor | Are product security objectives governed, measured, owned and aligned with enterprise risk and value delivery? | RACI, metrics, policy approvals, supplier governance, management reporting, risk acceptance |
| Product conformity reviewer | Does the technical file show cybersecurity requirements, design controls, vulnerability handling and post-market monitoring for the product? | Product Security File index, architecture, SBOM, test evidence, CVD records, update evidence |
| Customer security assessor | Can you prove the product is securely developed and supported during its lifecycle? | Secure SDLC summary, penetration test summary, vulnerability disclosure process, patch support policy, supplier assurance |
The same weak point will be exposed differently. If SBOMs are generated but not retained, the ISO auditor sees a record-control and operational-control issue. The NIST assessor sees an asset and vulnerability management weakness. The COBIT auditor sees weak governance over information assets. The product reviewer sees insufficient technical documentation.
A 30-step roadmap, adapted for CRA readiness
The Zenith Blueprint prevents compliance teams from jumping straight into document collection. For CRA, the 30-step roadmap becomes a product security evidence program.
Phase 1 begins with obligation and scope mapping. Identify which products, versions, components, cloud services and support processes are in scope. Confirm intended use, user categories, markets and security support period.
Phase 2 builds the evidence architecture. Define the Product Security File index, evidence owners, retention requirements, repository structure and approval workflow. Align with engineering systems rather than forcing manual uploads.
Phase 3 implements operating controls. Secure development, SBOM generation, vulnerability handling, supplier evidence, release gates, secure updates and incident escalation must operate as real processes.
Phase 4 tests audit readiness. Select a product release and perform a mock audit. Can the team retrieve the SBOM? Can they prove security testing? Can they show how a vulnerability was triaged? Can they connect supplier evidence to product components?
Phase 5 embeds surveillance and improvement. Post-market monitoring, vulnerability trend analysis, supplier reviews and management review inputs keep the file current.
| Four-week CRA readiness sprint | Output |
|---|---|
| Choose one flagship EU product | Product scope, versions, services and support period are defined |
| Create the Product Security File index | Evidence sections, owners and retention rules are documented |
| Map ISO/IEC 27001:2022 controls to file sections | Control-to-evidence mapping is available for audit |
| Attach one recent release as the evidence sample | Secure development, testing and release approval records are linked |
| Generate or validate the SBOM | Component inventory is tied to the release artifact |
| Trace one vulnerability from detection to closure | CVD, triage, remediation, communication and closure evidence is tested |
| Trace one supplier component to contract and security evidence | Supplier security evidence is connected to the product |
| Review post-market monitoring signals for the last quarter | Field intelligence and risk review are documented |
| Record gaps as ISMS corrective actions | CRA weaknesses become managed control improvements |
| Report readiness status to management | Executives receive evidence maturity, not vague control activity |
This sprint usually reveals the truth quickly. Organizations rarely fail because they lack all controls. They fail because controls are not connected at product level.
Common CRA readiness gaps before 2026
Across software vendors, device manufacturers and connected-service providers, recurring gaps are consistent.
First, the ISMS scope is too corporate. It covers the organization, but not enough product lifecycle detail. The fix is to create product-level annexes and evidence files.
Second, SBOMs exist but are not trusted. They are generated by tools but not reviewed, approved, retained or connected to vulnerability decisions. The fix is SBOM governance, not only SBOM production.
Third, CVD is public-facing but not operationally mature. Reports arrive, but triage criteria, response targets, advisory approvals and closure evidence are inconsistent. The fix is to integrate CVD with vulnerability management, incident management and release management.
Fourth, supplier evidence is too shallow. Critical suppliers are approved commercially but not assessed for product security impact. The fix is supplier classification by product risk and mandatory evidence for critical components.
Fifth, post-market monitoring is reactive. Teams respond to urgent vulnerabilities but do not run periodic product risk reviews. The fix is scheduled post-market security review tied to management reporting.
Sixth, audit evidence is over-manual. Compliance teams chase screenshots. The fix is evidence-by-design, using engineering systems, ticketing workflows and repositories as authoritative sources.
Build the evidence file before the deadline builds it for you
The Cyber Resilience Act rewards organizations that can prove product security as an operating discipline. It creates risk for organizations that treat evidence as a last-minute compliance exercise.
Start with one product. Build one Product Security File. Map it to ISO/IEC 27001:2022 and ISO/IEC 27002:2022. Attach secure development evidence, SBOM, CVD records, supplier assurance and post-market monitoring. Run an audit simulation before someone external does it for you.
Clarysec can help you accelerate that journey with the Zenith Blueprint, Zenith Controls, the Enterprise Secure development policy, Vulnerability management policy, Asset management policy, Third-party and supplier security policy, Logging and monitoring policy, and Information Security Incident Management Policy.
Your most important CRA 2026 question is not, “Do we have security controls?”
It is, “Can we prove product security, release by release, component by component, vulnerability by vulnerability, after the product is already in the market?”
Build the evidence file now, connect it to your ISMS, and make every future product release audit-ready by design.
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
