/annex-a-deep-dive

description: Deep dive analysis of ISO 27001 Annex A control domains with implementation guidance

ISO 27001 Annex A Control Domain Deep Dive

Provides comprehensive analysis of ISO 27001:2022 Annex A control domains, including control objectives, implementation guidance, cloud-specific patterns, common pitfalls, and certification audit readiness.

Usage

/iso:annex-a-deep-dive <domain> [options]

Arguments

• `$1` - Control domain: "A.5" (Organizational), "A.6" (People), "A.7" (Physical), "A.8" (Technological)
• `$2` - Options (optional): `--environment=cloud|hybrid`, `--show-gaps`, `--certification-focus`

Examples

# Deep dive on Organizational Controls (A.5)
/iso:annex-a-deep-dive A.5

# Deep dive on Technological Controls for cloud
/iso:annex-a-deep-dive A.8 --environment=cloud

# Show gaps only (controls not implemented)
/iso:annex-a-deep-dive A.8 --show-gaps

# Certification audit focus
/iso:annex-a-deep-dive A.6 --certification-focus

Output - A.8 Technological Controls

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ISO 27001:2022 ANNEX A DEEP DIVE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Domain: A.8 - Technological Controls
Total Controls: 34
Environment: Cloud (AWS)
Certification Focus: Stage 2 audit preparation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DOMAIN OVERVIEW
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Purpose:
  Technological controls address the technical security measures needed to
  protect information systems, networks, and data. This domain covers everything
  from endpoint security and access management to cryptography and secure
  development.

Key Themes:
  - User endpoint devices and remote working
  - Access control and authentication
  - System configuration and hardening
  - Cryptography and data protection
  - Secure development lifecycle
  - Network security
  - Logging and monitoring
  - Backup and resilience

Control Count: 34 controls (largest domain in Annex A)
Typical Implementation Time: 6-12 months (cloud environment)
Average Cost: $150,000-$300,000 (including tools and implementation)

Common Audit Findings:
  - Insufficient logging and monitoring (A.8.15, A.8.16)
  - Weak cryptography or key management (A.8.24)
  - Inadequate patch management (A.8.8)
  - Poor configuration management (A.8.9)
  - Insufficient backup testing (A.8.13)

Maturity Levels:
  Level 1 (Ad-hoc): Manual processes, inconsistent implementation
  Level 2 (Defined): Documented procedures, some automation
  Level 3 (Managed): Automated controls, regular testing
  Level 4 (Optimized): Continuous monitoring, self-healing systems

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CRITICAL CONTROLS (Must Implement First)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

A.8.2 - Privileged Access Rights
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Control Objective:
  To limit and control the allocation and use of privileged access rights.

Why Critical:
  Privileged accounts (admin, root, database admin) are the #1 target for
  attackers. Compromise of privileged credentials leads to complete system
  compromise, data breaches, and massive damage.

ISO Requirements:
  - Privileged access rights allocated based on business need
  - Regular review of privileged access (more frequent than normal access)
  - Privileged actions logged and monitored
  - Separation of privileged accounts from normal user accounts
  - Additional authentication for privileged access

Cloud Implementation (AWS):

  IAM Best Practices:
    ✓ No direct AdministratorAccess policy assignments
    ✓ Use permission sets with least privilege
    ✓ Require MFA for all privileged access
    ✓ Use AWS IAM Identity Center with time-limited sessions
    ✓ Separate admin accounts from daily-use accounts

  Privileged Access Management:
    ```terraform
    # Example: Time-limited privileged access
    resource "aws_iam_role" "admin" {
      name = "EmergencyAdminAccess"

      assume_role_policy = jsonencode({
        Version = "2012-10-17"
        Statement = [{
          Effect = "Allow"
          Principal = {
            AWS = "arn:aws:iam::${var.account_id}:root"
          }
          Action = "sts:AssumeRole"
          Condition = {
            IpAddress = {
              "aws:SourceIp" = var.corporate_ip_ranges
            }
            Bool = {
              "aws:MultiFactorAuthPresent" = "true"
            }
          }
        }]
      })

      max_session_duration = 3600  # 1 hour maximum
    }

    # Log all privileged actions
    resource "aws_cloudtrail" "admin_actions" {
      name           = "admin-audit-trail"
      s3_bucket_name = aws_s3_bucket.admin_logs.id

      event_selector {
        read_write_type           = "All"
        include_management_events = true

        # Filter for privileged API calls
        data_resource {
          type   = "AWS::IAM::Role"
          values = ["arn:aws:iam::${var.account_id}:role/Admin*"]
        }
      }
    }

Monitoring and Alerting:

• CloudWatch alarm for AssumeRole with Admin policies
• GuardDuty for privilege escalation attempts
• Access Analyzer for overly permissive policies

Review Process:

• Monthly review of all privileged access assignments
• Quarterly justification required (business need)
• Automatic revocation after 90 days if not used
• Manager + CISO approval for privileged access

Common Pitfalls: ❌ Giving developers AdministratorAccess "temporarily" (never removed) ❌ Shared admin accounts (cannot attribute actions) ❌ No MFA requirement for admin access ❌ Privileged access never reviewed (orphaned admin accounts) ❌ No logging of privileged actions

Evidence for Audit: □ IAM policy documents showing least privilege □ MFA enforcement configuration □ Monthly privileged access review reports □ CloudTrail logs of admin API calls □ Privileged access request/approval tickets □ Session duration