ISO 27001:2022 Annex A Controls — What Changed and What Engineering Teams Need to Address

Why the 2022 Revision Matters If You Have an Existing Implementation

ISO 27001:2022 replaced the 2013 version, with a transition deadline of October 31, 2025. Organizations that were certified under the 2013 standard needed to recertify under 2022 by that date. For companies implementing ISO 27001 for the first time, the 2022 standard is the only applicable version.

The structural change — from 114 controls in 14 categories to 93 controls in 4 themes — is less significant than it appears at first. Most of the reduction came from merging overlapping controls and consolidating related items. The actual security requirements did not become lighter; they became more organized. The 11 genuinely new controls, however, address areas that were not formally covered in 2013: threat intelligence, cloud security, data masking, physical security monitoring, and configuration management specifically for cloud environments.

If your organization was certified under 2013, the transition work involves: conducting a gap analysis against the new controls structure, addressing the 11 new control requirements, updating your Statement of Applicability to reflect the new numbering, and having your certification body perform a transition audit.

The Four Themes: Organizational, People, Physical, Technological

The 2022 revision replaced the 14 domain categories of 2013 with four attribute-based themes. Each theme covers different types of controls:

Theme 5: Organizational Controls (37 controls)

Organizational controls cover policies, procedures, and governance — the management framework that supports the technical controls. This theme includes information security policies, roles and responsibilities, threat intelligence (A.5.7, new in 2022), supplier security, incident management, and business continuity. For SaaS companies, the organizational controls are often easier to implement but harder to evidence — they require documented processes with records of execution, not just configuration screenshots.

Theme 6: People Controls (8 controls)

People controls cover the security responsibilities of personnel. This includes pre-employment background screening (A.6.1), terms of employment (A.6.2), information security awareness training (A.6.3), disciplinary processes (A.6.4), remote working (A.6.7, significantly expanded in 2022 to reflect current work patterns), and confidentiality requirements. The remote working control is particularly relevant for companies with distributed teams — it requires documented policies covering endpoint security, VPN use, and physical security of home office environments.

Theme 7: Physical Controls (14 controls)

Physical controls cover the security of physical environments where information assets are processed or stored. For most SaaS companies using cloud infrastructure, the physical controls at the data center level are inherited from the cloud provider — AWS, GCP, and Azure publish their physical security controls in their SOC 2 reports. What remains for the SaaS company is office security: secure work areas, clear desk policy, visitor management, and physical security monitoring (A.7.4, new in 2022, covering CCTV and access monitoring in sensitive areas).

Theme 8: Technological Controls (34 controls)

Technological controls are the most directly relevant for engineering teams. This theme covers access control, authentication, cryptography, network security, vulnerability management, configuration management, malware protection, logging, and monitoring. The 11 new controls introduced in 2022 are primarily in this theme.

The 11 New Controls in ISO 27001:2022

These controls did not exist in the 2013 standard and represent genuinely new implementation requirements:

A.5.7 — Threat Intelligence

Requires organizations to collect and analyze information about threats to determine appropriate controls. In practice, this means subscribing to threat intelligence sources relevant to your industry and infrastructure, reviewing threat intelligence on a regular schedule, and documenting how threat information has informed your security control decisions. For SaaS companies, cloud provider security bulletins, CISA advisories, and MITRE ATT&CK updates are common sources.

A.5.23 — Information Security for Use of Cloud Services

Addresses the specific security requirements for cloud service usage, including cloud service selection criteria, contractual security requirements for cloud providers, and ongoing monitoring of cloud security. This maps closely to SOC 2 CC9.2 vendor management, and organizations with SOC 2 programs often find the evidence already exists — they just need to document it against this control number.

A.5.30 — ICT Readiness for Business Continuity

Requires planning for the availability of ICT (information and communication technology) systems during disruptions, including failover, recovery time objectives, and testing. This goes beyond the basic business continuity plan requirement to specifically address technology-level continuity planning.

A.7.4 — Physical Security Monitoring

Requires monitoring of premises for unauthorized physical access. For most SaaS companies, this means documenting the physical security controls at office locations — CCTV coverage, access card logs, visitor management records. Cloud infrastructure physical security is typically covered by provider controls.

A.8.9 — Configuration Management

Establishes a requirement for managing configurations across hardware, software, services, and networks. This directly covers the configuration drift scenario discussed in our article on how configuration drift creates compliance gaps. The control requires documented configuration baselines, a change management process for configurations, and monitoring for unauthorized changes.

A.8.10 — Information Deletion

Requires the deletion of information when it is no longer needed, covering both storage systems and portable media. For SaaS companies, this translates to documented data retention and deletion policies with evidence of execution — demonstrating that data is actually deleted at the end of retention periods, not just that a policy exists.

A.8.11 — Data Masking

Requires the masking of sensitive data based on access policy requirements. This applies to production data access patterns — developers who need access to production systems for debugging should see masked PII. Audit logs should not contain unmasked sensitive data. Test environments should not contain production data unless it is properly masked.

A.8.12 — Data Leakage Prevention

Requires technical controls to prevent unauthorized disclosure of sensitive information. For SaaS companies, this typically involves data loss prevention (DLP) tools, email filtering for sensitive content, and endpoint controls that prevent data export to unauthorized media or services.

A.8.16 — Monitoring Activities

Requires monitoring of networks, systems, and applications to detect anomalous behavior. This is a consolidation and clarification of monitoring requirements from 2013, but its explicit addition as a distinct control increases audit scrutiny on the specific monitoring controls in place. Evidence needs to show not just that monitoring tools are deployed but that alerts are being reviewed and actioned.

A.8.23 — Web Filtering

Requires controlling access to external websites to protect systems from malware and unauthorized content. For cloud-native companies, this often means DNS-layer filtering (tools like Cisco Umbrella or Cloudflare Gateway) and endpoint web filtering policies.

A.8.28 — Secure Coding

Requires the application of secure coding principles in software development. This is the most engineering-specific of the new controls. Evidence includes SAST (static analysis security testing) tool configuration and results, code review policies with security-specific checklist items, developer security training records, and documentation of secure coding standards in your development process.

Mapping ISO 27001 to SOC 2 for Dual Certification

Organizations pursuing both SOC 2 and ISO 27001 can achieve significant efficiency through control mapping. The frameworks share substantial overlap — roughly 70% of SOC 2 evidence satisfies corresponding ISO 27001 control requirements, though the documentation format and audit approach differ.

The practical approach is to design your evidence collection around both frameworks simultaneously. CompliRun maintains a control mapping that shows which evidence collection events satisfy requirements in both frameworks. When it pulls CloudTrail logs for SOC 2 CC7.2 monitoring evidence, the same collection satisfies ISO 27001 A.8.16. When it documents access reviews for SOC 2 CC6.3, the same records satisfy ISO 27001 A.8.2 (privileged access rights).

The areas with least overlap — where ISO 27001 requires evidence that SOC 2 does not — are primarily in the organizational and people themes: threat intelligence documentation, physical security monitoring records, remote working policy implementation, and the specific documentation requirements for the new controls described above.

Practical Implementation Priority for Engineering Teams

If you are implementing ISO 27001 for the first time or transitioning from the 2013 standard, the engineering-relevant new controls break into two priority groups:

Implement immediately (automated or low overhead): A.8.9 (configuration management) — if you have continuous infrastructure monitoring running, this is largely covered. A.8.16 (monitoring activities) — same as above. A.8.23 (web filtering) — typically a one-time tool deployment. A.8.28 (secure coding) — if you already run SAST in your CI pipeline, document it and add security review checklist items to your code review process.

Require process design (more overhead): A.5.7 (threat intelligence) — requires setting up a regular review process and documenting how intelligence informs decisions. A.8.11 (data masking) — requires an audit of where PII appears in non-production contexts and implementing masking where needed. A.8.12 (data leakage prevention) — requires a DLP tool deployment and configuration, then ongoing policy management.