Risk analysis with ISO 27001 Annex A: Template, Method and SoA

According to ISO/IEC 27001:2022 Section 6.1.2, risk analysis is the basis of every information security management system (ISMS). It requires systematic identification, analysis and assessment of information security risks as well as subsequent treatment via the Statement of Applicability (SoA, Section 6.1.3). The new version of the standard from October 2022 brings a complete restructuring of Appendix A: 93 controls in four subject groups (organisational, personnel, physical, technological) instead of the previous 114 controls in 14 domains. Anyone who continues to carry out the risk analysis according to the old structure will lose the ability to certify during the transition period until October 31, 2026 and thus also the central contractual requirements in tenders, cyber insurance and supplier audits.

This article describes how an audit-proof template for the risk analysis is structured, which fields are mandatory, how the 93 controls from Appendix A are incorporated into the treatment and how the result creates a seamless SoA. It is aimed at information security officers (ISB), those responsible for ISMS development and management of medium and large companies. In the end, you will know the minimum components, common pitfalls in audits, the integration with NIS-2 and GDPR and how a compliance platform and officer-as-a-service like CIVAC reduces the maintenance effort for risk analysis. The information applies equally to initial certification and re-certification.

Section 6.1.2 of ISO/IEC 27001:2022 requires a documented method for identifying, analysing and assessing information security risks. The method must be consistent, valid and comparable so that repeated applications produce comparable results. Three requirements are central: defined risk criteria (probability, impact, threshold values), identification of the risk owners and the application of the method to all information assets within the scope of the ISMS. The supplementary ISO/IEC 27005:2022 provides comprehensive guidance on this, but is not mandatory.

In practice, most organisations choose a risk-based approach with a qualitative or semi-quantitative scale (around 1 to 5 for probability and impact, risk value as a product). Quantitative methods (FAIR, Value at Risk) are also permitted, provided the method is documented and applied consistently. Important: The method must be defined before the first use; subsequent adjustment requires a management decision and a new risk register.

The selection of the method directly influences the audit maturity. Auditors ask whether the method is appropriate, whether it is repeatable and whether the results are consistent with the risk treatment measures. A pure Excel list without documented methodology will not be accepted. Anyone who is interested in the connection between ISO 27001 and the BSI standard protection will find a compact overview of the transitional obligations in the document ISO 27001:2022 Transition October 2026. CIVAC provides the methodology description and the risk register as a template. The templates are designed in such a way that they are suitable for both initial certifications and ongoing surveillance audits and do not require any method changes. The appointment certificate, signed, filed, verifiable.

An audit-proof template for the risk analysis includes ten mandatory columns per risk entry. This structure fully meets the requirements of Sections 6.1.2 and 6.1.3 and allows direct interlinking with the SoA and the 93 controls from Appendix A. Anyone who prepares the template by role (HR, IT, Sales) saves considerable time in the initial recording and avoids inconsistent granularity between departments.

1. Asset or Process: concrete name, clearly related to the scope assignable.
2. Risk scenario: short description of the threat and its potential occurrence.
3. Threat: source (internal, external, technical, human).
4. Vulnerability: concrete gap that makes the scenario possible.
5. Existing measures: existing controls including reference to Appendix A.
6. Probability: Scale 1 to 5 with justification.
7. Impact: Scale 1 to 5 according to protection goal (confidentiality, integrity, availability).
8. Risk value: Product probability times impact.
9. Treatment option: avoid, reduce, transfer, accept.
10. Risk owner: by name, with date of Acceptance.

In addition, two fields should be maintained: the residual risk after measure (residual risk) and the reference to the SoA line. This closes the bridge to the Statement of Applicability. Anyone who maintains the template in Excel will usually experience inconsistencies between the risk register and the SoA after two updates. In a CIVAC workspace, both documents are technically linked; every change to the risk triggers an SoA adjustment. This prevents an auditor from finding different statuses in the sample. The integration with the asset register, incident management and the supplier list can also be mapped in the workspace without creating duplicate data. Audit-proof, documented, 6.1.3-proof.

The revision of ISO/IEC 27001:2022 has completely restructured Annex A. Instead of 14 domains with 114 controls (old version), there are now 93 controls in four topic groups. This new structure makes the assignment to risk analysis much easier and better reflects operational reality. The associated ISO/IEC 27002:2022 has also been restructured and now provides guidelines, attributes and purposes for each control, which makes implementation much easier.

• A.5 Organizational controls (37 controls): Guidelines, roles, asset management, supplier management, whistleblowers, threat intelligence.
• A.6 Person-related controls (8 controls): Screening, Confidentiality declarations, termination of employment, disciplinary procedures.
• A.7 Physical Controls (14 Controls): Access security, security areas, protection against natural hazards, maintenance.
• A.8 Technological Controls (34 Controls): End devices, access control, cryptography, backups, logging, vulnerability management, secure development.

Eleven controls are completely under revision new, including A.5.7 Threat intelligence, A.5.30 ICT readiness for business continuity, A.7.4 Physical security monitoring, A.8.9 Configuration management, A.8.10 Information deletion, A.8.11 Data masking, A.8.12 Data leakage prevention, A.8.16 Monitoring activities, A.8.23 Web filtering, A.8.28 Secure programming. Anyone who does not address these new controls in the risk analysis will have a problem in the transition audit. CIVAC maintains a template with standard measures for all 93 controls, so that the ISB only has to adapt to company-specific areas. In addition, a mapping table shows which controls from the 2013 version correspond to which 2022 controls, so that existing measures do not have to be redeveloped. Others run compliance like a filing cabinet. We run it like software.

Section 6.1.3 lit. d ISO/IEC 27001:2022 requires the Statement of Applicability (SoA). It is the central bridging document between risk analysis and controls. For each of the 93 controls, it must be justified whether it is used (Applicable) or excluded (Not Applicable) and what risks or requirements this decision entails. The SoA is not only relevant internally, but is explicitly requested in many supplier audits and cyber insurance policies.

A complete SoA line contains: control number and title, status (used, planned, excluded), justification with reference to risk ID or compliance requirement (GDPR, NIS-2, sector-specific), reference to measures (internal policy, technical solution), person responsible and date of last assessment. Blanket statements such as not applicable without justification are not accepted in audit practice. In the Stage 2 audit, the auditor will specifically check individual controls from the SoA and test the effectiveness of the measures.

Anyone who maintains the SoA by hand in Word risks inconsistencies with the risk register. Anyone taking on a new risk may need to activate two or three controls, update the SoA and adjust the associated measures. These cross-references are technically stored in the CIVAC compliance platform and in the officer-as-a-service model. Licence the workspace for your internal representatives, or have our representatives order it. Anyone who orders the ISB externally will receive the risk register and SoA as an ongoing service with a two working day SLA. This means that the bridge between the method document and the audit release is in one hand and the effort for the annual re-evaluation is significantly reduced.

Section 6.1.3 ISO/IEC 27001:2022 lists four risk treatment options: Avoid (stop activity), Mitigate (implement measures), Transfer (insurance, outsourcing), Accept (accept residual risk). Every choice must be justified. The most common option is Reduce, the most demanding is Accept, as management as the risk owner must formally agree. Transferring also has clear limits, because not every risk can be insured or completely passed on to third parties.

Residual risks are generally unavoidable. Auditors check whether acceptance is within the acceptance framework that was previously defined in the risk methodology. A typical definition: Risks with a risk value of 1 to 5 are accepted without further measures, 6 to 10 are reduced with standard measures, 11 to 15 with extended measures, 16 to 25 require a management decision to accept or avoid them. Anyone who does not document the acceptance framework loses the consistency check. A quarterly report to the management on changes in residual risks has also proven successful in practice and creates transparency at the level of the supervisory body.

The residual risk acceptance must be explicitly documented by those responsible in accordance with Section 6.1.3 lit. f. In practice, this is often the risk board or management. The signature with date is part of every accepted residual risk. In CIVAC, this mechanic is stored as a workflow: acceptance required, reminder to those responsible, escalation if the deadline is exceeded. Deadline begins as soon as we become aware of it. Audit-proof, documented, 6.1.3-proof. Anyone who operates multiple locations or subsidiaries should consolidate the acceptance thresholds into a group guideline. This means that the risk attitude within the group remains consistent and individual business areas cannot independently set riskier standards.

An ISO 27001 risk analysis does not exist in a vacuum. The NIS 2 Directive (implementation of the BSIG amendment, in Germany 2026) explicitly requires risk management for essential and important facilities in accordance with Art. 21 NIS 2 Directive with ten minimum measures, which are around 80 percent identical to controls from Annex A ISO/IEC 27001:2022. Anyone who is ISO 27001 certified has a significant lead in NIS 2 implementation. The 24/72-hour reporting path for significant incidents according to NIS-2 can also be docked to the ISO incident mechanics.

The GDPR also intervenes in the risk analysis. Art. 32 GDPR requires security of processing, Art. 35 GDPR requires a data protection impact assessment in cases of high risk. Both obligations can be linked to the ISO 27001 risk analysis as long as the template contains a column for affected personal data and a DPIA reference column. Sector-specific requirements from TISAX (automobile), C5 (cloud), PCI DSS (card payment) or industry-specific BSI basic protection modules are supplemented.

If you maintain all of these standards in separate Excel tables, you will quickly lose track. CIVAC offers a mapping function: A measure in the risk register is automatically assigned to the relevant requirements (ISO 27001 A.x.y, NIS-2 Art. 21 No. z, GDPR Art. 32). Licence the workspace for your internal representatives, or have our representatives order it. A broader overview of the NIS 2 situation is provided by NIS 2 implementation Germany 2026. Anyone who is an essential or important facility within the meaning of NIS-2 should have checked the mapping at least before the audit date. The auditor calls, the evidence is ready.

Six findings can be derived from Stage 2 audits that appear in almost every initial certification. Eliminating them before the audit significantly reduces the effort required for evidence and follow-up measures. These weak points are documented in the activity reports of the national accreditation bodies (DAkkS for Germany). Even experienced ISB teams often underestimate these points in the initial assessment because they focus on detailed operational questions instead of structural gaps.

First: Methodology documented, but not consistently applied. Risks are assessed partly according to the old scale and partly according to the new scale. Second: risk owners are missing or not named. Third party: Acceptance of residual risk without signature or date. Fourth: SoA justifications are general (e.g. not applicable without reference). Fifth: New Appendix A controls (A.5.7 Threat Intelligence, A.5.30 ICT Readiness) are not addressed in the SoA. Sixth: Risk analysis and list of procedures according to Art. 30 GDPR are not interlinked.

Each of these findings can be specifically remedied. CIVAC provides 490 audit templates, twelve of which are related to information security: risk register, SoA template, methodology description, acceptance framework, threat intelligence process, ICT preparedness plan, vulnerability management template, asset register, classification, logging requirements, crypto policy, secure software development. The templates are provided with § and ISO references. Anyone who carries out the risk analysis in a workspace avoids the typical inconsistencies in everyday care. Audit-proof, documented, 6.1.3-proof. A preliminary self-check along these six fields takes around 6 hours with the platform and provides a clear prioritization for the audit. This allows the preparation of Stage 1 and Stage 2 to be planned in a structured manner and the risk of unplanned extensions can be reduced.

Section 8.2 ISO/IEC 27001:2022 requires a scheduled assessment of information security risks at regular intervals and when there are significant changes. The market standard is an annual full review plus event-related updates. An ad hoc update is required for new business processes, relocation, vendor changes, major technological changes (cloud migration, M&A) or new legal requirements. Even after a significant security incident, an extraordinary assessment is mandatory, as the threat situation and the effectiveness of the measures can be reassessed.

The maintenance cycle includes six steps: reviewing the incidents and audit findings that have occurred since the last review, updating the asset register, checking the threat situation (threat intelligence, BSI situation report), adjusting the risk assessment, updating the risk treatment plan and SoA, formal release by the risk function. Every step requires proof, audit logs must be audit-proof.

In practice, this cycle fails due to three points: lack of resources in the ISB team, lack of connection to incident management, lack of technical versioning. This is exactly where the CIVAC platform comes into play: The workspace connects risk analysis, incident register, asset register and SoA in an EU data residence under an ISO/IEC 27001:2022 ISMS. A change to the asset triggers a review task for the risk. Licence the workspace for your internal representatives, or have our representatives order it. Both models use the same audit trail and provide identical quality of evidence. Anyone who operates multiple representative roles (ISB, DSB, ESG) in the same workspace also benefits from shared governance. This turns the annual risk review from a multi-week project into a structured multi-day process with clear responsibilities.

The risk analysis according to ISO/IEC 27001:2022 is the backbone of every ISMS. Anyone who runs it as static Excel risks inconsistencies, findings and certification in the transition audit. CIVAC sees itself as a compliance platform and officer-as-a-service: The workspace bundles risk registers, SoA, asset registers, incident management and 490 audit templates in an EU data residence under an ISO/IEC 27001:2022 ISMS. 93 controls from Appendix A are stored in the platform with standard measures, so that the ISB only has to adapt to company-specific positions.

Two reference models are available. Licence the workspace for your internal representatives and run the ISMS function yourself, or have our representatives appointed and hand over the function completely. In both cases you receive 490 audit templates, 25 representative role profiles and a reporting line that is included in DAkkS audits. SLA: 2 business days instead of 2 to 6 weeks. If you combine several officer roles (ISB, DSB, ESG, IMB), you noticeably reduce the overall effort of the compliance function.

If you want to audit an existing risk analysis or set up a new one, the next step is a structural discussion. We review your current risk register and SoA, identify the gaps according to the 93 controls and provide an implementation plan with specific deadlines. Turn reading into an assignment. Write to info@civac.de or use the contact form at civac.de/faq. The auditor calls, the evidence is ready. You then decide whether you want to manage the function internally or hand it over entirely to CIVAC. A typical structural discussion lasts 45 minutes; the gap analysis is available after 5 working days.