The risk assessment tells you what risks exist. Annex A is the catalogue of controls designed to address them. The challenge of Phase 3 and Phase 4 is bridging from one to the other — selecting the right controls, justifying the selection, building the Statement of Applicability that connects every control decision to its rationale, and then actually implementing the controls with evidence quality that survives certification audit scrutiny.
This is the point where the conceptual work of risk assessment becomes concrete implementation work. MFA must actually be deployed, not just listed as a planned control. Vulnerability scanning must actually run on a schedule, not just appear in a procedure document. Supplier contracts must actually contain security addenda, not just reference the supplier security policy. The gap between 'plan to implement' and 'evidence of implementation' is where most certification audit nonconformities originate.
This article covers the complete control selection and implementation journey: the 8-step process from risk assessment to implemented controls, the Annex A domain structure in 2022 with emphasis on the 11 new controls, a prioritized implementation guide, and sample SoA entries and risk treatment plan records that demonstrate the level of documentation quality certification auditors expect.
The 8-Step Control Selection Process
Control selection is not a list review — it is a structured process that begins with the risk assessment results and ends with implemented, evidenced controls. The process below maps the eight steps from risk assessment output to control implementation:
| # | Step | What it requires |
| 1 | Complete the Risk Assessment | Identify all risks exceeding the acceptance threshold. Each risk must be addressed by the risk treatment plan — either through control implementation, risk acceptance with justification, risk avoidance, or risk transfer. |
| 2 | Identify Controls from Risk Assessment | For each risk being modified (treated with controls), identify which Annex A controls address the threat or vulnerability driving the risk. Multiple risks may point to the same control. One risk may require multiple controls. |
| 3 | Review the Full Annex A List | Review all 93 Annex A controls against the in-scope services, systems, and processes. Identify any controls that are applicable regardless of risk assessment findings — for example, controls required by UU PDP or POJK regulations, or controls required by contractual obligations. |
| 4 | Make Applicability Decisions | For each Annex A control: (a) Applicable and will be implemented, (b) Applicable but currently not implemented — include in risk treatment plan, (c) Not applicable — document justification. Three are the only valid states. |
| 5 | Document in the Statement of Applicability | Record every control decision in the SoA: applicability status, justification, and implementation status. The SoA must account for all 93 controls — no omissions. Include cross-references to the risk register entries that drove each decision. |
| 6 | Produce the Risk Treatment Plan | For every control that is applicable but not yet implemented, create a risk treatment plan entry: what will be implemented, who is responsible, what resources are needed, what is the target completion date, and what the expected residual risk will be post-implementation. |
| 7 | Get Risk Owner Sign-Off | Present the risk treatment plan and residual risk estimates to risk owners for formal acceptance. Risk owners must review and approve both the treatment decisions for risks in their domain AND the residual risks that will remain after treatment is complete. |
| 8 | Implement | Execute the risk treatment plan. Implement controls per the plan. Collect evidence of implementation. Update the SoA implementation status as controls are deployed. Track against milestones. |
| THE RISK-DRIVEN SELECTION PRINCIPLE | Every applicable control in the SoA must be traceable to either a risk in the risk register or a specific external obligation (regulatory, contractual, or best practice). Controls that appear in the SoA without a documented reason — selected because 'it seemed appropriate' or 'we wanted to be thorough' — signal to auditors that the control selection was not genuinely risk-driven. The traceability between risk register entries and SoA control decisions is one of the most tested aspects of a certification audit. |
Annex A 2022: Four Domains, 93 Controls
ISO 27001:2022 reorganized Annex A from the 14-domain, 114-control structure of the 2013 version into a cleaner 4-domain, 93-control architecture. Understanding this structure — what each domain covers and where the 2022 additions are concentrated — helps implementers navigate control selection and prioritize their work:
| Domain | Controls | Focus areas | Key 2022 additions |
| 5 — Organizational | 39 controls | Policies, roles, threat intelligence, asset management, information classification, supplier relationships, incident management, business continuity, compliance | 5.7 Threat intelligence (NEW), 5.23 Cloud services security (NEW), 5.30 ICT readiness for BC (NEW) |
| 6 — People | 8 controls | Pre-employment screening, terms and conditions, security responsibilities, awareness training, disciplinary process, departure, remote working, information security events | No new controls in 2022. Structure unchanged from 2013. |
| 7 — Physical | 14 controls | Physical security perimeters, entry controls, securing offices and facilities, physical security monitoring, protection against physical threats, equipment security, clear desk, supporting utilities, cabling, equipment maintenance | 7.4 Physical security monitoring (NEW) |
| 8 — Technological | 34 controls | Endpoint security, privileged access management, access restriction, secure authentication, vulnerability management, configuration management, information deletion, data masking, DLP, logging, monitoring, web filtering, secure coding | 8.9 Configuration management (NEW), 8.10 Information deletion (NEW), 8.11 Data masking (NEW), 8.12 DLP (NEW), 8.16 Monitoring activities (NEW), 8.23 Web filtering (NEW), 8.28 Secure coding (NEW) — 7 of 11 new controls are in this domain |
The 2022 revision concentrated most of the new controls in the Technological domain (Domain 8) — reflecting the reality that cloud adoption, software development security, and data protection controls have become the most significant information security gaps for modern organizations. If your organization is heavily cloud-native or develops its own software, Domain 8 deserves proportionally more attention in both the risk assessment and control implementation phases.
The 11 New Controls: Deep Dive
The 11 new controls introduced in ISO 27001:2022 represent the areas where the 2013 version had aged most visibly. For Indonesian regulated organizations, many of these controls have direct regulatory parallels — particularly around cloud security, data deletion, and secure software development. The table below covers all 11 with implementation guidance and Indonesian regulatory context:
| Control | Title & Domain | Why it was added / What it requires | Implementation action + Indonesian regulatory relevance |
| 5.7 | Threat intelligence Domain: Org | Organizations must now actively gather and analyze threat intelligence relevant to their environment. Passive security is no longer sufficient — you must know what threats are active in your sector. | Identify threat intelligence sources (BSSN, ENISA, commercial TI feeds). Assign responsibility for regular review. Document how TI feeds into risk assessment updates. Regulatory: Directly supports risk assessment quality. Demonstrates proactive risk management to OJK and BI examiners. |
| 5.23 | Information security for use of cloud services Domain: Org | Cloud adoption is near-universal for Indonesian organizations. This control requires explicit governance of cloud security — not just using cloud, but governing it with defined security requirements. | Establish cloud services policy. Define security requirements for each cloud provider category. Include in supplier security management program. Regulatory: Directly addresses cloud data residency concerns under UU PDP and OJK cloud governance guidance. |
| 5.30 | ICT readiness for business continuity Domain: Org | Bridges the gap between information security and business continuity management. Requires ICT continuity to be planned, implemented, and tested as part of the ISMS. | Define ICT recovery objectives (RTO/RPO). Test recovery procedures. Integrate with Annex A 5.29 (IS in BCM). Consider ISO 22301 integration. Regulatory: Addresses OJK requirements for business continuity planning in financial institutions. |
| 7.4 | Physical security monitoring Domain: Physical | Introduces explicit requirements for monitoring of physical premises — CCTV, access control logs, intrusion detection. Particularly relevant for organizations with data center facilities. | Assess physical monitoring requirements for in-scope locations. Implement CCTV and access logging where applicable. Define monitoring procedures. Regulatory: Relevant for organizations with physical server infrastructure or office locations handling sensitive data. |
| 8.9 | Configuration management Domain: Tech | Formalizes the requirement to manage system configurations securely — not just deploy systems but maintain their secure configuration throughout their lifecycle. | Define approved baseline configurations for servers, network devices, cloud resources. Implement configuration drift detection. Integrate with change management. Regulatory: Addresses a major source of security incidents — misconfiguration. Particularly relevant for cloud-native organizations. |
| 8.10 | Information deletion Domain: Tech | Explicitly addresses the right to erasure and retention management. Personal data must be securely deleted when retention periods expire or at data subject request. | Define retention schedules for all data categories. Implement secure deletion procedures. Automate deletion for inactive records where possible. Document deletion evidence. Regulatory: Directly maps to UU PDP Article 39 (right to erasure). One of the most directly UU PDP-relevant controls in the 2022 revision. |
| 8.11 | Data masking Domain: Tech | Requires that sensitive data is masked in non-production environments to prevent exposure during development, testing, and analytics activities. | Identify non-production environments containing or derived from production data. Implement data masking or synthetic data generation for test datasets. Regulatory: Addresses a common UU PDP risk — developers accessing real customer data in development environments. |
| 8.12 | Data leakage prevention Domain: Tech | Requires controls to prevent unauthorized extraction of sensitive data from the organization's systems — DLP tooling, email controls, or equivalent measures. | Assess DLP requirements based on risk assessment findings. Implement endpoint or email DLP for high-risk data flows. Define monitoring and alert procedures. Regulatory: Addresses major concern in regulated financial services — unauthorized exfiltration of customer financial data. |
| 8.16 | Monitoring activities Domain: Tech | Requires monitoring of networks, systems, and applications to detect anomalous behavior and security events. Goes beyond logging — requires active monitoring and response. | Define monitoring scope and alert thresholds. Assign responsibility for alert review. Establish response procedures for anomaly detections. Regulatory: Critical for detecting insider threats and external attacks early — directly reduces MTTD metric. |
| 8.23 | Web filtering Domain: Tech | Requires controls over access to external websites to reduce exposure to malware, phishing sites, and data exfiltration channels. | Implement DNS filtering or web proxy. Define category-based access policies. Review and tune regularly. Regulatory: Particularly relevant for organizations where staff web browsing represents a significant malware delivery vector. |
| 8.28 | Secure coding Domain: Tech | Formalizes secure development practices — requiring that software developed by or for the organization follows documented secure coding standards. | Adopt or create secure coding standard (reference OWASP). Implement SAST in CI/CD pipeline. Include security testing in SDLC. Train developers. Regulatory: Critical for fintech and tech organizations developing customer-facing applications. Reduces vulnerability introduction at source. |
| 2022 transition note: Organizations that certified under ISO 27001:2013 must have transitioned to the 2022 version by October 2025. As of early 2026, all valid certificates are based on the 2022 version. If your SoA was built against the 2013 control set (114 controls, 14 domains), it requires a structural update to reflect the 2022 restructuring and to make explicit applicability decisions on all 11 new controls. This is not optional — an SoA that does not address the 2022 control set will generate a major nonconformity. |
Control Implementation Priority Guide
Not all controls have equal urgency. The priority of control implementation should be driven by risk assessment findings, regulatory obligations, and the certification timeline. The table below provides an implementation priority guide for the most commonly required and highest-impact controls, organized into implementation waves aligned with the Phase 4 timeline from Article 3.1:
| Control | Title | Wave | Risk driver | Effort | Implementation notes |
| 8.5 | Secure authentication (MFA) | Wave 1 | HIGH to CRITICAL | Medium — 2–4 weeks | MFA on ALL accounts — not just privileged. Common gap: MFA deployed for admins but not standard users. Verify implementation completeness. |
| 8.2 | Privileged access rights management | Wave 1 | HIGH to CRITICAL | Medium — 2–4 weeks | Formal process for granting, reviewing, and revoking privileged access. PAM tooling for high-risk environments. Access review evidence required for Stage 2. |
| 8.8 | Management of technical vulnerabilities | Wave 1 | HIGH | Low-Medium — 1–2 weeks to initiate | Regular vulnerability scanning with formal remediation SLAs. First scan before Stage 2 audit required. Documented patch management procedure. |
| 5.24-5.26 | Information security incident management | Wave 1 | HIGH — regulatory | Medium — 2–3 weeks | Incident response procedure with UU PDP 14-day notification trigger. First tabletop exercise before Stage 2. Incident log active with all events recorded. |
| 6.3 | Security awareness training | Wave 1 | HIGH — audit risk | Medium — 3–5 weeks to deploy | All staff trained before Stage 2. LMS with completion records. Phishing simulation recommended. No flexibility on completion rate — auditors sample staff. |
| 8.3 | Information access restriction | Wave 1-2 | HIGH | Medium — ongoing process | Formal access request and approval process. Quarterly access review with documented evidence. First complete review cycle required before Stage 2. |
| 8.7 | Protection against malware | Wave 2 | HIGH | Low — likely partially in place | Endpoint protection on all devices. Define standard for approved solutions and coverage verification. |
| 8.13 | Information backup | Wave 2 | HIGH | Low-Medium | Backup policy with defined RTO/RPO. Backup test results documented. Immutable backup for ransomware resilience where critical systems are in scope. |
| 8.20 | Networks security | Wave 2 | Medium-High | Medium | Network segmentation for production environments. Firewall rules documented and reviewed. Traffic monitoring between segments. |
| 5.19-5.22 | Supplier relationship security | Wave 2 | High — common gap | High — contract negotiation | Security addenda in all critical supplier contracts. Supplier register complete. Annual monitoring reviews scheduled. |
| 8.9 | Configuration management (NEW 2022) | Wave 2-3 | Medium-High | Medium-High | Baseline configurations documented. Drift detection implemented. Integrated with change management process. |
| 8.28 | Secure coding (NEW 2022) | Wave 2-3 | Medium — tech orgs only | Medium | Secure coding standard adopted. SAST in CI/CD. Developer training completed. For technology/fintech organizations developing own software. |
| 8.10 | Information deletion (NEW 2022) | Wave 2-3 | High — UU PDP | Medium | Retention schedules defined for all data categories. Deletion procedures documented and operational. Critical for UU PDP Article 39 compliance. |
| 8.15 | Logging | Wave 3 | Medium | Medium | Centralized logging from all in-scope systems. Log retention meeting regulatory minimum. Alert rules configured for key security events. |
| 7.1-7.3 | Physical security | Wave 3 | Scope-dependent | Variable | Scope-dependent. Remote-only organizations address through device security and clean desk policy. Physical location organizations require perimeter controls and access logging. |
| Wave 1 is non-negotiable for Stage 2: The controls in Wave 1 — MFA, privileged access management, vulnerability scanning, incident management, and security awareness training — must be fully implemented and evidenced before the Stage 2 certification audit. These controls represent the minimum credible security baseline that certification auditors expect to find operational. Partial implementation of Wave 1 controls is the most common cause of major nonconformities in first-cycle certification audits. |
The Statement of Applicability: Building It Right
The Statement of Applicability (SoA) is the central control decision document of the ISMS. It must account for every one of the 93 Annex A controls — declaring each as applicable or excluded, documenting the justification, and recording the implementation status. It is both an audit artifact and an operational management tool — the SoA tells the story of every security decision the organization has made about which controls it will and will not implement.
A strong SoA has four properties. Every applicable control references a specific risk register entry or regulatory obligation that drove the decision. Every excluded control has a defensible justification — not 'not applicable' with no further explanation, but a specific reason why this control does not apply to this organization's scope. Implementation status is current and accurate — not the status at the time the SoA was first produced. And the SoA has a version history showing when control decisions changed and why.
The sample below illustrates eight SoA entries — including two new 2022 controls, one justified exclusion, and a mix of implementation statuses — at the level of quality that certification auditors expect:
| Ctrl | Control title | Applicable? | Implemented? | Risk reference(s) | Justification |
| 5.7 | Threat intelligence | YES | Partial | R-001, R-002 | Applicable — identified as essential for maintaining current risk assessment quality in a dynamic threat environment. Threat intelligence subscription procured Q1 2026; integration with risk assessment process in progress. |
| 5.23 | Information security for use of cloud services | YES | Yes | R-001, R-005 | Applicable — production infrastructure hosted on AWS. Cloud security requirements documented in supplier security policy and AWS security addendum. Annual SOC 2 Type II report review scheduled. |
| 8.5 | Secure authentication | YES | Partial | R-001, R-002 | Applicable — critical control for R-001 (credential compromise). MFA implemented for all privileged accounts. Standard user MFA rollout in progress — target completion Q2 2026. |
| 8.10 | Information deletion | YES | Partial | R-UUP-001 | Applicable — UU PDP Article 39 right to erasure obligation. Customer-initiated deletion workflow in development. Automated retention-based deletion for inactive records: Q3 2026. |
| 8.28 | Secure coding | YES | Yes | R-002 | Applicable — in-house software development for customer-facing payment platform. Secure coding standard v1.0 published. SAST integrated in CI/CD. Developer training completed Q4 2025. |
| 7.4 | Physical security monitoring | NO | N/A | N/A | EXCLUDED — Organization operates fully remotely with no physical office premises. No in-scope systems are located in physical facilities under organizational control. Physical security monitoring is not applicable. Remote work security addressed through A.6.7. |
| 8.21 | Security of network services | YES | Yes | R-001, R-005 | Applicable — production systems dependent on cloud networking. VPC security groups configured. Network traffic monitoring enabled. VPN for all remote production access. |
| 8.12 | Data leakage prevention | YES | Not started | R-001, R-002 | Applicable — identified in risk assessment as relevant for preventing unauthorized exfiltration of customer payment data. DLP tool procurement in scope for Q3 2026 budget. |
| SoA maintenance discipline: The SoA must be maintained as a living document throughout the ISMS lifecycle. When new risks are identified that require new controls, the SoA must be updated. When business changes make previously excluded controls applicable, the SoA must be updated. When the risk treatment plan completes implementation of a control, the implementation status in the SoA must be updated. An SoA that shows 'Not yet implemented' for controls that have been deployed for six months signals poor document maintenance and will generate a finding. |
The Risk Treatment Plan: Evidence of Intent
The risk treatment plan (RTP) documents the specific actions the organization will take to implement the controls selected through the risk assessment and SoA process. It is not a high-level summary — it is an operational commitment document with named owners, specific actions, target dates, and expected residual risk outcomes.
Certification auditors examine the risk treatment plan against three questions: Is it specific enough to be implemented? Is there evidence that implementation is actually happening? Does the timeline connect to the certification schedule? An RTP that was produced six months ago and shows no progress against any line items signals that the treatment plan exists on paper only.
The sample below shows seven risk treatment plan entries for the risk register from Article 3.4, demonstrating the required level of specificity — with the R-006 entry (UU PDP notification procedure) particularly relevant for Indonesian regulated organizations:
| Risk | Control | Action | Owner | Target date | Status | Residual risk |
| R-001 | A.8.5 | Deploy MFA for all standard user accounts (privileged accounts already complete) | Head of IT | Q2 2026 | In Progress | Score 12 → 8 after full MFA deployment |
| R-001 | A.8.2 | Implement Privileged Access Management (PAM) solution for database admin accounts | Head of IT | Q2 2026 | In Progress | Score 20 → 12 with MFA + PAM + access review |
| R-002 | A.8.20 | Implement API rate limiting and authentication validation on customer-facing endpoints | Head of Engineering | Q1 2026 | Complete | Score 15 → 8 |
| R-002 | A.8.29 | Add API security testing gate to CI/CD pipeline — block deployment on critical API vulnerabilities | Head of Engineering | Q2 2026 | In Progress | Included in R-002 residual above |
| R-003 | A.8.13 | Implement immutable backup for production systems — tested recovery from backup | Head of IT | Q3 2026 | Not Started | Score 12 → 6 with immutable backup + EDR |
| R-004 | A.6.5 | Implement formal offboarding procedure — IT access revocation within 4 hours of departure confirmation | HR Director | Q1 2026 | Complete | Score 9 → 4 |
| R-006 | A.5.26 | Document and test UU PDP breach notification procedure — tabletop exercise with Legal and IT | Legal Director | Q1 2026 | In Progress | Score 12 → 4 with documented procedure and trained team |
| Residual risk calculation: The residual risk column in the RTP is not a formality — it is the risk owner's forward-looking acceptance of the risk level that will remain after all planned controls are implemented. If the residual risk after treatment is still HIGH, the risk owner must formally accept this at the treatment decision point. If the organization's risk acceptance criteria do not permit HIGH residual risks to be accepted, additional controls must be planned or the risk acceptance criteria must be formally reviewed by top management. |
Evidence of Control Implementation
Selecting controls and planning implementation is Phase 3 work. Implementing controls and producing evidence is Phase 4 work. The evidence requirement is non-negotiable: for every applicable control in the SoA, there must be evidence that the control exists and is functioning. Documentation that a control 'will be implemented' or 'is planned' does not satisfy a Stage 2 audit requirement.
Evidence quality varies by control type. Technical controls require configuration records, system screenshots, audit log exports, or tool output reports. Process controls require procedure documents, training completion records, process execution records, or completed forms. People controls require role descriptions, training records, and signed acknowledgments. The table below maps the evidence types expected for a selection of key controls:
- MFA (A.8.5): Identity management system report showing MFA enabled for all accounts. Screenshot of MFA configuration. Access log sample showing MFA authentication events.
- Vulnerability management (A.8.8): Automated scan reports from the last two scanning cycles. Remediation tickets for identified vulnerabilities. Patch management records showing critical patch deployment within SLA.
- Access review (A.8.3): Completed access review report with reviewer sign-off. Access changes made as a result of the review. Next review date documented.
- Security awareness training (6.3): LMS completion report showing all in-scope staff completion. Training content version confirming currency. Phishing simulation results if used.
- Incident management (A.5.24): Documented incident management procedure. Incident log showing events recorded since procedure was activated. Tabletop exercise record or real incident response evidence.
- Supplier security (A.5.20): Executed supplier contracts with security addenda. Supplier security questionnaire responses. Annual monitoring review records for critical suppliers.
| Bitlion evidence management: Bitlion's platform allows control evidence to be uploaded directly against each SoA control entry — creating a searchable, auditor-accessible evidence library that maps every piece of evidence to the control it demonstrates. During Stage 1 and Stage 2 audits, the ISMS Lead can navigate the certification body directly to evidence rather than searching through file shares and email archives. Evidence expiry dates can be set for time-limited records (e.g. access reviews expire quarterly) with automatic notifications when refresh is due. |
Common Control Implementation Mistakes
Implementing controls for audit visibility rather than risk reduction
Organizations sometimes implement controls that are easy to demonstrate (produce a policy document, enable a default security feature) in preference to controls that are harder to evidence but more important for actual risk reduction. This pattern is most visible in the access review and vulnerability management areas — the reviews get completed and the scans run in the month before the audit but not consistently throughout the year. Auditors test for operational evidence patterns, not just pre-audit evidence spikes.
Declaring controls 'implemented' before implementation is complete
SoA entries showing 'Implemented' for controls that are still being deployed — because the SoA was updated based on the plan rather than the reality — create audit discrepancies when the auditor asks for evidence. If MFA is deployed for privileged accounts but not yet for standard users, the implementation status should be 'Partial', not 'Yes'. Accuracy in the SoA is more important than optics.
Not collecting evidence at the time of control operation
The most common evidence problem: controls operate correctly but no evidence is collected at the time of operation. The quarterly access review is conducted, access changes are made, but no report is exported or signed off. Six months later, when the auditor asks for access review records, nothing can be produced that predates the audit preparation period. Build evidence collection into the control operation process — not as a retrospective activity.
| The partial implementation trap: The most common major nonconformity in first-cycle certification audits is a critical control declared as 'Implemented' in the SoA but found by the auditor to be only partially deployed. MFA enabled for admins only. Vulnerability scanning for web applications but not production servers. Security awareness training completed by 87% of staff with 13% still pending. Each of these is a partial implementation, not a complete one. Stage 2 auditors probe implementation completeness specifically — count the exceptions, not just the deployments. |
From Controls to a Functioning Security Program
Control implementation is not the end goal. It is the means by which the risk assessment findings are addressed and the ISMS becomes operationally real. Controls that are implemented correctly, evidenced thoroughly, and maintained consistently form the technical and procedural backbone of an ISMS that genuinely protects the organization.
The organizations that certify fastest and maintain their certification most cleanly are those that treat control implementation as an operational program, not a documentation project. They deploy controls against specific risks. They collect evidence as a natural output of control operation. They monitor controls continuously rather than testing them quarterly. And when controls fail or degrade, they fix them through the corrective action process rather than waiting for the next audit cycle to surface the gap.
This operational orientation — controls deployed against risks, evidenced continuously, monitored actively, and maintained proactively — is what separates a certifiable ISMS from a certified compliance exercise.