ISO/IEC 27001:2022
ActiveCore framework
Best for: Organizations that need to prove a functioning ISMS to enterprise buyers, government procurement, or regulated-sector partners. Certification is contractually required in financial services, healthcare, SaaS, and telecoms. There is no revenue or size threshold; a 15-person startup selling to banks faces the same commercial requirement as a Fortune 500. GDPR Article 32, EU NIS2, and APAC sector regulators treat ISO 27001 as evidence of appropriate technical and organizational measures.
| Mandatory? | Voluntary — demanded by B2B contracts |
|---|---|
| Who validates? | Accredited certification body (IAF member). No self-assessment. |
| Renewal | 3-year cert; annual surveillance |
| Observation period | Surveillance: years 1 and 2 |
| Governing body | International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), with national accreditation bodies (e.g., UKAS, ANAB) overseeing certification bodies., ISO/IEC 27001:2022. Official source |
Get started
Point the module source at the ISO/IEC 27001:2022 endpoint and pin a version range you reviewed:
module "..." {
source = "iso27001.compliance.tf/terraform-aws-modules/<module>/aws"
version = "<version>"
}iso27001.compliance.tf lists every ISO/IEC 27001:2022 module with its versions, inputs and outputs.
What compliance.tf covers and what you handle
| Area | Compliance.tf automates | You handle |
|---|---|---|
| Encryption at Rest | Checks encryption configuration across API Gateway caches, Athena workgroups, Backup recovery points, and Bedrock invocation logs. Validates KMS key usage where applicable. Maps to Annex A control A.8.24. | Documenting a cryptographic policy covering algorithms, key lengths, and approved use cases. Configuring and auditing KMS key rotation schedules. Maintaining key access policies and reviewing them during internal audits per Clause 9.2. |
| Logging and Monitoring | Validates that logging is enabled on API Gateway stages, AppSync GraphQL APIs, Athena workgroups, and Bedrock model invocations. Detects services where logging was disabled or never configured. | Defining log retention periods per A.8.15. Implementing centralized log review processes and alerting thresholds. Conducting periodic reviews of log data to satisfy A.8.16 monitoring requirements. |
| Network Exposure | Detects publicly accessible API Gateway REST endpoints and AppStream fleets with default internet access enabled. Flags resources that violate network segmentation expectations. | Maintaining network architecture diagrams (A.8.20). Documenting and reviewing firewall rules, security groups, and NACLs. Performing risk-based security testing (for example, penetration testing) where required by your ISMS and risk treatment plan, rather than as a blanket Clause 8.1 mandate. |
| Backup and Recovery | Verifies that AWS Backup plans and vaults exist in active regions, that recovery points are encrypted, and that backup report plans are configured. Checks multi-AZ deployment for Auto Scaling groups and CloudFront origin failover. | Defining and documenting RTO/RPO targets. Testing recovery procedures at planned intervals based on risk and business requirements, consistent with A.5.30. Maintaining business continuity plans and reporting results to management review (Clause 9.3). |
| Account Governance | Validates that AWS accounts have a security contact registered, that contact details are current, and that accounts belong to AWS Organizations for centralized management. | Establishing the ISMS governance structure (Clauses 5.1 through 5.3). Defining roles and responsibilities per A.5.2. Conducting management reviews and maintaining records of decisions. |
| Certificate Lifecycle | Flags ACM certificates expiring within 30 days, giving teams lead time to renew or rotate before expiration causes a service disruption. | Maintaining a certificate inventory. Defining renewal procedures and ownership. Integrating certificate monitoring into incident management processes per A.5.24. |
Controls by category
93 of 166 mapped controls are Enforced by compliance.tf modules at terraform plan. The other 73 are Mapped only: ISO/IEC 27001:2022 lists them, no compliance.tf module checks them.
Cryptographic Controls (A.8.24)
A.8.24 (Use of cryptography) requires a documented cryptographic policy specifying algorithms, key lengths, and key management procedures. Auditors verify encryption at rest across data stores, caches, and backups, and check certificate lifecycle management. Expired or nearly expired ACM certificates are a consistent finding and signal weak operational controls. Be prepared to show KMS key policies and rotation schedules.
Logging, Monitoring, and Accountability (A.8.15, A.8.16)
The core evidence request here is proof that logging is enabled across all in-scope services, directly supporting A.8.15 (Logging) and A.8.16 (Monitoring activities). Assessors want to see centralized log aggregation, documented retention periods, and evidence of regular review. Field-level logging for APIs like AppSync and invocation logging for Bedrock are where gaps appear most often, particularly for services added after initial certification.
Network Security and Access Restriction (A.8.20, A.8.21, A.8.22)
Publicly exposed API endpoints and AppStream fleets with default internet access enabled are the most common non-conformities in this category, mapped to A.8.20 (Networks security), A.8.21 (Security of network services), and A.8.22 (Segregation of networks). Expect to produce network diagrams showing segmentation, evidence of private endpoint usage, and written justification for any public-facing resource.
| Control | Status |
|---|---|
| AppStream fleets should have default internet access disabled | Mapped |
Additional controls (160)
AWS AppSync (1)
| Control | Status |
|---|---|
| AppSync API caches should have encryption in transit enabled | Enforced |
AWS Certificate Manager (1)
| Control | Status |
|---|---|
| ACM certificates should not use wildcard certificates | Mapped |
AWS CloudTrail (4)
AWS CodeBuild (4)
AWS Database Migration Service (2)
AWS IAM (9)
AWS KMS (1)
| Control | Status |
|---|---|
| KMS CMK rotation should be enabled | Enforced |
AWS Lambda (4)
AWS Step Functions (1)
| Control | Status |
|---|---|
| Step Functions state machines should have logging enabled | Enforced |
AWS WAF (1)
| Control | Status |
|---|---|
| WAFv2 rules should have CloudWatch metrics enabled | Enforced |
Amazon CloudFront (4)
Amazon CloudWatch (1)
| Control | Status |
|---|---|
| CloudWatch log groups should have retention period of at least 365 days | Enforced |
Amazon CloudWatch Logs (1)
| Control | Status |
|---|---|
| Log groups should have encryption at rest enabled | Enforced |
Amazon DocumentDB (2)
Amazon DynamoDB (2)
| Control | Status |
|---|---|
| DynamoDB tables should have AWS KMS encryption enabled | Enforced |
| DynamoDB tables should have encryption enabled | Enforced |
Amazon DynamoDB Accelerator (2)
Amazon EBS (2)
| Control | Status |
|---|---|
| Attached EBS volumes should have encryption enabled | Enforced |
| EBS snapshots should be encrypted | Mapped |
Amazon EC2 (9)
Amazon ECS (1)
| Control | Status |
|---|---|
| ECS services should not have public IP addresses assigned automatically | Enforced |
Amazon EFS (2)
| Control | Status |
|---|---|
| EFS file systems should have encryption at rest enabled | Enforced |
| EFS file systems should be encrypted with CMK | Enforced |
Amazon EKS (4)
Amazon ElastiCache (5)
Amazon Kinesis (3)
Amazon MQ (2)
Amazon MSK (1)
| Control | Status |
|---|---|
| MSK clusters should require TLS for client-broker connections | Enforced |
Amazon Neptune (3)
Amazon OpenSearch Service (7)
Amazon RDS (15)
Amazon Redshift (8)
Amazon S3 (14)
Amazon SNS (1)
| Control | Status |
|---|---|
| SNS topics should be encrypted at rest | Enforced |
Amazon SQS (2)
| Control | Status |
|---|---|
| SQS queues should have encryption at rest enabled | Enforced |
| SQS queues should be encrypted with KMS CMK | Enforced |
Amazon SageMaker (5)
Amazon VPC (7)
Elastic Load Balancing (3)
Other (26)
Related frameworks
| Framework | Control overlap | Note |
|---|---|---|
| NIST Cybersecurity Framework v2.0 | Medium 59% | |
| AWS Well-Architected Framework v10 | Medium 57% | |
| SOC 2 | Medium 56% |
Frequently asked questions
Does ISO 27001 apply to my organization if we only use cloud services and have no on-premises infrastructure?
Yes. ISO 27001 applies to information security regardless of where systems run. Cloud-only organizations define their ISMS scope around cloud accounts, SaaS tools, and remote workforce practices. The 2022 revision added control A.5.23 (Information security for use of cloud services) specifically for cloud environments. Your Clause 4.3 scope statement will reference AWS accounts, regions, and services rather than physical data centers.
How long does ISO 27001 certification take from scratch?
Expect 6 to 14 months for a first-time certification. Smaller organizations (under 50 employees) with a focused scope can finish in 6 to 8 months. Larger enterprises with multiple business units, regions, or complex supply chains commonly need 10 to 14 months. The time breaks down roughly as: ISMS design and documentation (2 to 4 months), implementation and evidence gathering (3 to 6 months), internal audit and management review (1 month), Stage 1 audit (1 to 2 weeks), remediation of findings (2 to 6 weeks), and Stage 2 audit (1 to 2 weeks).
What changed between ISO 27001:2013 and 2022, and do I need to recertify?
The management system clauses (4 through 10) had minor wording changes. The significant change was in Annex A: 114 controls across 14 domains were reorganized into 93 controls across 4 themes (Organizational, People, Physical, Technological). Eleven new controls were added, including A.5.7 (Threat intelligence), A.5.23 (Cloud services), A.8.11 (Data masking), and A.8.12 (Data leakage prevention). Organizations certified under the 2013 version had until October 31, 2025, to transition. If you have not transitioned, your certification has expired.
How much overlap can I expect if we are already SOC 2 Type II compliant?
Roughly 60 to 65 percent of evidence from a SOC 2 Type II engagement transfers to ISO 27001. Technical controls for encryption, logging, access management, and incident response overlap significantly. The gap is primarily in ISO 27001's management system requirements: you will need an ISMS scope statement (Clause 4.3), a formal risk assessment methodology and risk treatment plan (Clauses 6.1.2 and 6.1.3), a Statement of Applicability, an internal audit program (Clause 9.2), and management review minutes (Clause 9.3). None of these have direct SOC 2 equivalents.
What does the compliance.tf coverage for ISO 27001 actually prove to an auditor?
Automated checks prove that specific technical configurations existed at the time of the scan. An auditor may accept PowerPipe benchmark results as supporting evidence for Annex A.8 technological controls, specifically that encryption, logging, network restrictions, and backup configurations are in place. That said, compliance.tf produces no evidence for the management system (Clauses 4 through 10), people controls (A.6), or physical controls (A.7). You still need documented policies, risk assessments, training records, supplier agreements, and internal audit reports.