Infrastructure Compliance Auditor

Infrastructure Compliance Auditor

Cross-cutting infrastructure security audit across ALL compliance frameworks. Replaces manual Vanta-style checks with deterministic, repeatable, evidence-generating infrastructure audits covering cloud, DNS, TLS, endpoints, access control, network, containers, CI/CD, secrets, logging, and physical security. Maps 250+ controls to 10 standards (SOC 2, ISO 27001, HIPAA, GDPR, PCI-DSS, NIS2, DORA, NIST CSF, FedRAMP, CCPA) with severity-weighted scoring.

Core Capabilities

• 11 audit domains — cloud (AWS/Azure/GCP), DNS, TLS/SSL, endpoints, access control, network, container/K8s, CI/CD, secrets, logging/monitoring, physical security
• 250+ controls — each with a check ID, severity rating, and multi-framework mapping
• Framework mapping — collect-evidence-once, map-to-many strategy across 10 standards
• Deterministic scoring — severity-weighted per-domain and overall scores (0-100) with an audit-readiness rating
• Evidence generation — JSON and markdown reports suitable for auditor consumption

When to Use

Reach for this skill on: "infrastructure audit", "cloud security audit", "infrastructure compliance", "DNS security audit", "TLS audit", "endpoint security", "access control audit", "network security assessment", "infrastructure security", "cloud compliance", "Vanta alternative", "compliance automation", "security posture assessment", "hardware security keys", or "YubiKey compliance".

Quick Start

Run Full Infrastructure Audit

python scripts/infra_audit_runner.py --config infrastructure.json --output audit_report.json

Audit DNS Security for a Domain

python scripts/dns_security_checker.py --domain example.com --output dns_report.json

Audit Access Controls

python scripts/access_control_auditor.py --config access_controls.json --output access_report.json

Generate Compliance-Mapped Report

python scripts/infra_audit_runner.py --config infrastructure.json --frameworks soc2,iso27001,hipaa --format markdown --output compliance_report.md

Tools

References

Load the reference that matches the task — keep this file lean and pull detail on demand:

• [references/audit-control-catalog.md](references/audit-control-catalog.md) — the full 250+ control catalog across all 11 audit domains plus the framework coverage matrix. Read when you need exact check IDs, controls, severities, and framework mappings for any domain.
• [references/audit-workflows.md](references/audit-workflows.md) — audit workflows, pre/post-audit validation checklists, the severity-weighted scoring methodology, and success criteria. Read when planning or executing an audit and interpreting scores.
• [references/tool-reference.md](references/tool-reference.md) — CLI flag reference for the three audit scripts plus a troubleshooting table. Read when running the tools or diagnosing unexpected output.
• [references/cloud-security-baseline.md](references/cloud-security-baseline.md) — AWS / Azure / GCP CIS Benchmark deep-dive. Read for cloud-provider hardening detail beyond the catalog.
• [references/access-control-standards.md](references/access-control-standards.md) — MFA, SSO, PAM, Zero Trust, and YubiKey implementation standards. Read when designing identity and access controls.
• [references/compliance-framework-mapping.md](references/compliance-framework-mapping.md) — control-to-framework master mapping. Read when aligning evidence across multiple certifications.

Scope & Limitations

In Scope:

• Infrastructure security audit across 11 domains: Cloud, DNS, TLS/SSL, Endpoints, Access Control, Network, Containers/K8s, CI/CD, Secrets, Logging/Monitoring, Physical Security
• Framework mapping to 10 compliance standards: SOC 2, ISO 27001, HIPAA, GDPR, PCI-DSS, NIS2, DORA, NIST CSF, FedRAMP, CCPA
• 250+ individual control checks with severity-weighted scoring
• DNS security validation including SPF, DKIM, DMARC, DNSSEC, CAA, MTA-STS, and subdomain takeover risk
• Access control audit covering IdP, SSO, MFA, FIDO2/hardware keys, PAM, RBAC, service accounts, SSH keys, API keys, and Zero Trust
• Evidence-generating reports in JSON and markdown formats for auditor consumption

Out of Scope:

• Actual penetration testing, vulnerability scanning, or active exploitation -- this skill performs configuration-based assessment, not active testing
• Cloud provider API calls or live infrastructure scanning -- the tool works with JSON configuration input describing your infrastructure state
• Compliance certification or attestation -- this skill identifies gaps but does not replace formal SOC 2, ISO 27001, or PCI-DSS audits
• Application security testing (SAST/DAST) beyond CI/CD pipeline configuration checks
• Compliance program management, policy writing, or governance documentation

Important Notes:

• SOC 2 2026 best practices demand real-time monitoring dashboards flagging control deficiencies within 48 hours; periodic spot-checks are no longer sufficient
• Zero Trust architecture is increasingly expected across all frameworks; perimeter-based security alone is insufficient for SOC 2, ISO 27001, and NIS2
• Compliance automation platforms (Drata, Vanta, Sprinto) complement but do not replace the deterministic checks this tool provides

Integration Points

Access Control Standards Reference

Comprehensive guide to identity, authentication, authorization, and access governance covering MFA, SSO, PAM, Zero Trust, and hardware security key deployment.

---

1. Multi-Factor Authentication (MFA) Implementation

MFA Factor Types (Ranked by Security)

MFA Enforcement Policy

MANDATORY: MFA for 100% of accounts, no exceptions.

Privileged accounts (IdP admins, cloud admins, prod access):
  → FIDO2/WebAuthn hardware security key REQUIRED
  → TOTP and push DISABLED as fallback
  → Number matching enforced if push is used anywhere

Standard accounts (all employees):
  → TOTP minimum, FIDO2 preferred
  → Push with number matching acceptable
  → SMS/Email PROHIBITED

Service accounts:
  → No interactive MFA (machine accounts)
  → Use managed identity, Workload Identity, or OIDC federation
  → Short-lived credentials (STS, dynamic secrets)

External users (contractors, partners):
  → TOTP minimum
  → FIDO2 required for any admin access
  → Access time-limited and scoped

MFA Rollout Plan

Phase 1 — Admins (Week 1-2) 1. Procure hardware keys (2 per admin) 2. Register primary key with IdP 3. Register backup key, store securely 4. Configure IdP policy: require phishing-resistant MFA for admin roles 5. Disable TOTP/push fallback for admin accounts 6. Test authentication flow

Phase 2 — All Employees (Week 3-6) 1. Announce MFA requirement (2 weeks notice) 2. Provide self-service TOTP enrollment guide 3. Offer hardware key for employees who request it 4. Configure IdP policy: require MFA for all users 5. Grace period: 7 days to enroll 6. Auto-enforce after grace period (block unenrolled users)

Phase 3 — External Users (Week 7-8) 1. Notify external users of MFA requirement 2. Provide enrollment guide for TOTP 3. Enable MFA requirement for external identities 4. Support team trained for MFA help

Phishing-Resistant MFA Deep Dive

Why FIDO2/WebAuthn?

• Cryptographic proof bound to the specific website origin
• Cannot be phished — key will not respond to wrong origin
• No shared secrets (unlike TOTP which has a shared seed)
• Immune to real-time phishing proxies (evilginx, modlishka)
• Resistant to social engineering (no code to share)

How FIDO2 works:

Registration:
1. User visits IdP login
2. Browser prompts for security key
3. Key generates unique public/private key pair for that origin
4. Public key stored by IdP
5. Private key never leaves the hardware key

Authentication:
1. User visits IdP login, enters username
2. IdP sends challenge
3. Browser checks origin (example.okta.com) — MUST match registration
4. Key signs challenge with private key (requires touch + PIN)
5. IdP verifies signature with stored public key
6. If attacker's proxy presents wrong origin → key refuses to sign

---

2. Hardware Security Key Deployment (YubiKey)

YubiKey Product Selection

Recommendation: YubiKey 5C NFC for most employees (works with USB-C laptops and NFC-capable phones).

YubiKey Enrollment Process

Prerequisites:

• IdP supports FIDO2/WebAuthn (Okta, Azure AD, Google Workspace)
• User has 2 YubiKey devices (primary + backup)
• IT admin has configured FIDO2 as allowed authentication method

Step-by-Step Enrollment (Okta Example):

1. User logs into Okta dashboard
2. Navigate to Settings > Security Methods
3. Click "Set up" next to "Security Key or Biometric"
4. Insert YubiKey and click "Set up"
5. Browser prompts for security key
6. Touch the YubiKey sensor
7. Set a PIN when prompted (FIDO2 User Verification)
8. Key is registered — name it "Primary YubiKey"
9. Repeat steps 3-8 for backup key — name it "Backup YubiKey"
10. Store backup key in secure location (home safe, locked drawer)

Step-by-Step Enrollment (Azure AD/Entra ID):

1. Navigate to https://mysignins.microsoft.com/security-info
2. Click "Add sign-in method"
3. Select "Security key"
4. Choose "USB device"
5. Click "Next" — browser prompts for security key
6. Insert YubiKey and touch sensor
7. Create a PIN when prompted
8. Name the key and click "Done"
9. Repeat for backup key

Step-by-Step Enrollment (Google Workspace):

1. Go to myaccount.google.com/security
2. Under "Signing in to Google" click "2-Step Verification"
3. Click "Add security key"
4. Click "USB or Bluetooth"
5. Insert YubiKey and touch sensor
6. Name the key
7. Repeat for backup key
8. Admin: Enable Advanced Protection Program for admin accounts

YubiKey Policy Requirements

enrollment:
  keys_per_user: 2  # primary + backup
  backup_storage: "secure location (home safe, locked drawer, IT vault)"
  pin_required: true  # FIDO2 User Verification
  touch_required: true  # always require physical touch

key_management:
  inventory:
    track: [serial_number, assigned_user, issuance_date, status]
    review: quarterly
  lost_key_process:
    1: "User reports lost key immediately to IT"
    2: "IT revokes lost key in IdP within 1 hour"
    3: "User authenticates via backup key"
    4: "Identity reverification (video call + manager confirmation)"
    5: "New primary key issued and enrolled"
    6: "Incident logged in security ticketing system"
  stolen_key_process:
    1: "Same as lost key process"
    2: "Additional: security team assesses risk of compromised PIN"
    3: "If PIN may be compromised: force password reset + re-enroll all keys"

enforcement:
  admin_accounts:
    required: true
    fallback_allowed: false  # no TOTP/push fallback
  standard_accounts:
    required: false  # encouraged but not mandatory
    fallback_allowed: true  # TOTP fallback OK
  high_value_access:
    required: true  # production, financial, customer data
    fallback_allowed: false

YubiKey Inventory Spreadsheet Template

---

3. Single Sign-On (SSO) Configuration

Protocol Selection

SSO Security Requirements

Session Management:
  - Session timeout: maximum 8 hours for standard apps
  - Session timeout: maximum 1 hour for sensitive apps (finance, admin)
  - Idle timeout: 30 minutes
  - Force re-authentication for sensitive operations
  - Session tokens stored securely (HttpOnly, Secure, SameSite cookies)

Token Configuration:
  - SAML assertion validity: maximum 5 minutes
  - OIDC access token lifetime: maximum 1 hour
  - OIDC refresh token lifetime: maximum 8 hours (or until session timeout)
  - Token binding to client (if supported)

SAML Security:
  - Assertions MUST be signed
  - Assertions SHOULD be encrypted
  - NameID format: persistent or email
  - Single Logout (SLO) configured
  - Certificate rotation plan documented

OIDC Security:
  - Authorization Code flow with PKCE (not implicit flow)
  - State parameter used (CSRF protection)
  - Nonce parameter used (replay protection)
  - Token endpoint authentication: private_key_jwt or client_secret_post
  - Redirect URIs exactly match (no wildcards)

SCIM Provisioning

SCIM (System for Cross-domain Identity Management) v2.0:

Benefits:
- Automated user creation when employee joins
- Automated deactivation when employee leaves
- Group membership sync for RBAC
- Attribute sync (name, email, title, department)

Required SCIM Events:
1. User created → account provisioned in all integrated apps
2. User deactivated → account disabled in all apps within 1 hour
3. User group changed → permissions updated in all apps
4. User attribute changed → profile updated in all apps

Deprovisioning Checklist:
- [ ] IdP account disabled
- [ ] All SSO sessions revoked immediately
- [ ] All SCIM-provisioned accounts deactivated
- [ ] API keys revoked
- [ ] SSH keys revoked
- [ ] VPN access revoked
- [ ] Hardware security keys returned and deregistered
- [ ] Shared drives access removed
- [ ] Email forwarding configured (if needed)
- [ ] Offboarding ticket closed

---

4. Privileged Access Management (PAM)

PAM Architecture

Standard Access:
  User → IdP (SSO + MFA) → Application

Privileged Access:
  User → IdP (SSO + FIDO2) → PAM Platform → Approval Workflow → Time-Limited Session → Target System
                                                    ↓
                                              Session Recording
                                                    ↓
                                              Audit Log → SIEM

JIT (Just-In-Time) Access Implementation

jit_access:
  principles:
    - Zero standing privileges (no permanent admin access)
    - Access granted on demand, revoked automatically
    - Every access request requires justification
    - Time-limited sessions (maximum 4 hours)
    - All sessions recorded

  workflow:
    1_request:
      - User submits access request via PAM portal
      - Specifies: target system, role, duration, justification
    2_approval:
      - Auto-approve: pre-authorized break-glass (triggers alert)
      - Manager approval: standard privileged access
      - Security team approval: cross-environment access
      - Approval SLA: 30 minutes during business hours
    3_activation:
      - Temporary credentials generated
      - Session time limit enforced
      - Recording started
    4_deactivation:
      - Credentials automatically revoked at expiry
      - Session recording stored for 1 year
      - Activity logged to SIEM

  platform_options:
    - Azure PIM (Privileged Identity Management)
    - CyberArk Privileged Access Manager
    - HashiCorp Vault + Boundary
    - AWS IAM Identity Center
    - Okta Privileged Access
    - Teleport (SSH + K8s + DB access)

Break-Glass Procedure

break_glass:
  purpose: "Emergency access when normal approval workflow is unavailable"

  accounts:
    - Stored in physical safe + password manager (dual control)
    - Known to minimum 3 people (CTO, VP Engineering, Security Lead)
    - MFA configured with dedicated hardware keys stored with credentials
    - Tested quarterly (documented test results)

  activation_process:
    1: "Declare emergency (must be documented)"
    2: "Retrieve break-glass credentials (dual authorization)"
    3: "Activate account (triggers immediate alert to security team + management)"
    4: "Perform emergency actions"
    5: "Deactivate account immediately after use"
    6: "Rotate break-glass credentials"
    7: "Post-incident review within 48 hours"
    8: "Document all actions taken during break-glass session"

  monitoring:
    - Break-glass account login → immediate PagerDuty alert
    - All actions logged to immutable audit trail
    - Post-use review mandatory within 48 hours
    - Credentials rotated after every use

---

5. Role-Based Access Control (RBAC)

RBAC Model Design

Principle: Users get ZERO permissions by default.
Access granted ONLY through role assignment.
Roles map to job functions, NOT individuals.

Role Hierarchy Example:
├── Viewer (read-only access to assigned resources)
├── Editor (create/update in assigned resources)
├── Admin (full control of assigned resources)
├── Security Admin (security configuration, audit access)
├── Super Admin (organization-wide admin — JIT only)
└── Break-Glass (emergency full access — monitored)

Access Recertification Process

Quarterly Access Review:

Week 1: Generate access report
  - Export all user-role assignments from IdP
  - Export all service account permissions
  - Export all API key assignments
  - Flag: dormant accounts (>60 days no login)
  - Flag: excessive permissions (admin roles)
  - Flag: cross-environment access

Week 2: Manager review
  - Each manager reviews their team's access
  - For each access grant: Certify (keep) or Revoke
  - Must provide business justification for admin access
  - Deadline: 5 business days

Week 3: Remediation
  - Revoked access removed within 24 hours
  - Dormant accounts disabled
  - Excessive permissions right-sized
  - Missing access grants processed

Week 4: Report
  - Compliance report generated
  - Exceptions documented and approved
  - Metrics: total reviews, revocations, exceptions
  - Report filed as compliance evidence

Separation of Duties Matrix

---

6. Zero Trust Architecture

Zero Trust Principles

1. Never trust, always verify
   - Every access request verified regardless of network location
   - Internal network provides NO implicit trust
   - VPN does not equal trust

2. Least privilege access
   - Minimum permissions for the task
   - Time-limited access (JIT)
   - Scoped to specific resources

3. Assume breach
   - Design as if attackers are already inside
   - Microsegmentation limits lateral movement
   - Continuous monitoring for anomalies
   - Rapid detection and response

4. Verify explicitly
   - User identity (MFA, risk-based auth)
   - Device identity (MDM, device certificates)
   - Device posture (patched, encrypted, EDR running)
   - Request context (location, time, behavior)

5. Use data-driven decisions
   - Risk scoring for access decisions
   - Behavioral analytics (UEBA)
   - Continuous assessment (not just at login)

Zero Trust Implementation Roadmap

Phase 1 — Identity Foundation (Month 1-3) 1. Deploy centralized IdP with SSO 2. Enforce MFA for all users (FIDO2 for admins) 3. Implement SCIM provisioning 4. Remove shared accounts 5. Establish access review process

Phase 2 — Device Trust (Month 3-6) 1. Deploy MDM (Jamf, Intune, Kandji) 2. Enforce device compliance:

• Disk encryption
• OS version minimum
• EDR running
• Screen lock enabled

3. Device posture checked before access 4. BYOD containerization

Phase 3 — Application Security (Month 6-9) 1. All applications behind identity-aware proxy 2. SSO enforced (local auth disabled) 3. Session management configured 4. API authentication with OAuth 2.0 / OIDC 5. Service mesh for service-to-service auth

Phase 4 — Network Transformation (Month 9-12) 1. Microsegmentation deployed 2. VPN replaced with ZTNA 3. Network no longer determines trust 4. Egress filtering enforced 5. DNS security (DoH/DoT) deployed

Phase 5 — Continuous Verification (Month 12+) 1. Risk-based authentication (step-up MFA) 2. Continuous session evaluation 3. UEBA for anomaly detection 4. Automated response to high-risk events 5. Regular red team exercises to validate

Zero Trust Technology Stack

---

7. Service Account Governance

Service Account Lifecycle

1. Creation
   - Business justification required
   - Owner assigned (individual, not team)
   - Minimum permissions (principle of least privilege)
   - Expiration date set (maximum 1 year, renewable)
   - Registered in service account inventory

2. Operation
   - Credentials stored in secrets manager (never in code)
   - Automatic credential rotation (90 days maximum)
   - Usage monitored (anomaly detection)
   - Access logged to SIEM

3. Review (Quarterly)
   - Owner confirms still needed
   - Permissions validated (still minimum required)
   - Last usage checked (disable if >90 days idle)
   - Credentials rotation verified

4. Decommissioning
   - Credentials revoked
   - Service account disabled (not deleted — audit trail)
   - Associated resources reviewed
   - Removal documented

Service Account Security Rules

MUST:
- Have a unique identity (never share between services)
- Have an assigned human owner
- Use machine credentials (not human passwords)
- Store credentials in secrets manager
- Rotate credentials every 90 days
- Be inventoried and reviewed quarterly

MUST NOT:
- Use shared credentials between services
- Store credentials in source code
- Have interactive login capability (where possible)
- Have broader permissions than needed
- Persist beyond their required lifetime
- Use long-lived tokens when short-lived alternatives exist

---

8. SSH Key Management

SSH Key Best Practices

Key Algorithm (Preferred Order):
1. ED25519 (recommended — fast, secure, small keys)
2. ECDSA-SK (hardware-bound, FIDO2 security key)
3. ED25519-SK (hardware-bound, FIDO2 security key)
4. RSA 4096-bit (legacy compatibility)

Generate ED25519 key:
  ssh-keygen -t ed25519 -C "user@company.com"

Generate hardware-bound key (requires YubiKey):
  ssh-keygen -t ecdsa-sk -C "user@company.com"

PROHIBITED:
  - DSA (deprecated, removed from OpenSSH 9.0+)
  - RSA < 2048 bit
  - RSA < 4096 bit (for new keys)
  - ECDSA with NIST curves < 384 bit

SSH Certificate-Based Authentication

Benefits over raw public keys:
- Automatic expiration (no stale authorized_keys)
- Central revocation via CA
- No authorized_keys file management
- Audit trail of issued certificates
- Role-based access via certificate principals

Architecture:
  SSH CA (in Vault/Teleport) → Issues short-lived certificates
  User requests cert → CA verifies identity (IdP) → Issues 24h cert
  Server trusts CA → Accepts any valid cert from CA
  No authorized_keys needed on servers

Example (HashiCorp Vault):
  vault write ssh-client-signer/sign/my-role \
    public_key=@$HOME/.ssh/id_ed25519.pub \
    valid_principals="ubuntu,deploy" \
    ttl="24h"

sshd_config on servers:
  TrustedUserCAKeys /etc/ssh/trusted-user-ca-keys.pub
  AuthorizedPrincipalsFile /etc/ssh/auth-principals/%u

sshd_config Hardening

# /etc/ssh/sshd_config hardened configuration

# Authentication
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
LoginGraceTime 30

# Key algorithms
PubkeyAcceptedAlgorithms ssh-ed25519,sk-ssh-ed25519@openssh.com,ecdsa-sha2-nistp384,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256

# Ciphers and MACs
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org

# Session
ClientAliveInterval 300
ClientAliveCountMax 2
MaxSessions 2
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no

# Logging
LogLevel VERBOSE

---

Last Updated: March 2026 Covers: MFA, FIDO2, YubiKey, SSO, SCIM, PAM, RBAC, Zero Trust, Service Accounts, SSH

Infrastructure Audit Control Catalog

The full 250+ control catalog across all 11 audit domains plus the compliance framework mapping. Read this when you need the exact check IDs, controls, severities, and framework mappings for any domain (cloud, DNS, TLS, endpoint, access control, network, container/K8s, CI/CD, secrets, logging, physical security).

Audit Domains

1. Cloud Infrastructure Security

AWS Security Audit Checklist

IAM Policies and Roles

S3 Bucket Security

VPC Configuration

RDS Security

CloudTrail and Monitoring

KMS and Encryption

Lambda and Serverless Security

EKS/ECS Container Security

Azure Security Audit Checklist

Azure AD / Entra ID

Azure Network Security

Azure Key Vault

Azure Monitoring

Azure Storage Security

AKS Security

GCP Security Audit Checklist

GCP IAM and Service Accounts

GCP VPC and Network

GCP Security Services

GKE Security

---

2. DNS Security

Email Authentication Chain

SPF, DKIM, and DMARC form a layered email authentication system. ALL three must be configured correctly for effective protection against spoofing and phishing.

SPF (Sender Policy Framework)

SPF syntax reference:

v=spf1 include:_spf.google.com include:sendgrid.net ip4:203.0.113.0/24 -all

Key rules:

• Maximum 10 DNS lookups (include, a, mx, ptr, exists, redirect each count as 1)
• ip4 and ip6 mechanisms do NOT count toward the 10-lookup limit
• Nested includes count toward the limit
• Record must be a single TXT record (no multiple SPF records)
• Maximum 255 characters per DNS string (use string concatenation for longer records)

DKIM (DomainKeys Identified Mail)

DKIM record format:

selector._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."

DMARC (Domain-based Message Authentication, Reporting, and Conformance)

DMARC record format:

_dmarc.example.com IN TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-forensic@example.com; pct=100"

DMARC rollout strategy (avoid disrupting legitimate email): 1. p=none; rua=mailto:... — Monitor for 2-4 weeks 2. p=quarantine; pct=10 — Quarantine 10% of failing messages 3. p=quarantine; pct=50 — Increase gradually 4. p=quarantine; pct=100 — Full quarantine 5. p=reject; pct=100 — Full enforcement

DNSSEC

CAA (Certificate Authority Authorization)

CAA record format:

example.com IN CAA 0 issue "letsencrypt.org"
example.com IN CAA 0 issue "digicert.com"
example.com IN CAA 0 issuewild "letsencrypt.org"
example.com IN CAA 0 iodef "mailto:security@example.com"

MTA-STS and TLS-RPT

MTA-STS policy (at https://mta-sts.example.com/.well-known/mta-sts.txt):

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.example.com
max_age: 604800

Domain Security

---

3. TLS/SSL Security

Certificate Management

Protocol and Cipher Configuration

Recommended TLS 1.2 cipher suites (in order):

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

TLS 1.3 cipher suites (always use all three):

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

HTTP Security Headers

Internal TLS

---

4. Endpoint Security

Mobile Device Management (MDM)

Disk Encryption

Antivirus and EDR

OS Patch Management

Additional Endpoint Controls

---

5. Access Control and Authentication

Identity Provider (IdP) Configuration

Single Sign-On (SSO)

Multi-Factor Authentication (MFA)

Hardware Security Key (YubiKey) Implementation:

Enrollment process: 1. User registers primary YubiKey to IdP (Okta, Azure AD, Google Workspace) 2. User registers backup YubiKey (stored in secure location) 3. IdP policy updated to require FIDO2/WebAuthn for user 4. TOTP/push fallback disabled for privileged accounts

YubiKey policy requirements:

• Each user has minimum 2 registered keys (primary + backup)
• Backup key stored in secure, documented location
• PIN configured on YubiKey (FIDO2 user verification)
• Touch required for every authentication
• Bio Series (fingerprint) preferred for shared workstations
• Inventory of all issued keys maintained
• Lost key process: immediate revocation, identity reverification, new key issuance

IdP-specific configuration:

• Okta: Enroll YubiKey via FIDO2 (WebAuthn) factor, set Authentication Policy to require phishing-resistant MFA
• Azure AD/Entra ID: Configure FIDO2 security key in Authentication Methods, create Conditional Access policy requiring authentication strength "Phishing-resistant MFA"
• Google Workspace: Enroll security key in 2-Step Verification, enable Advanced Protection Program for admins

Privileged Access Management (PAM)

Role-Based Access Control (RBAC)

Service Account and API Key Governance

SSH Key Management

Zero Trust Architecture

---

6. Network Security

Firewall Configuration

Network Segmentation

Web Application Firewall (WAF)

DDoS Protection

VPN Configuration

Intrusion Detection/Prevention

---

7. Container and Kubernetes Security

Base Image Security

Container Runtime Security

Kubernetes Cluster Security

---

8. CI/CD Pipeline Security

Source Code Management

Security Scanning

Supply Chain Security

Deployment Security

---

9. Secrets Management

Secrets Management Solutions

Secret Rotation

Code and Repository Security

Hardware Security Modules (HSM)

---

10. Logging and Monitoring

Centralized Logging

SIEM

Retention and Integrity

Alerting and Detection

---

11. Physical Security

Data Center Security

Office Security

Media Disposal

---

12. Compliance Framework Mapping

Each control in this audit maps to one or more compliance frameworks. The mapping enables organizations pursuing multiple certifications to satisfy overlapping requirements with single implementations.

Supported Frameworks:

Framework Coverage Summary:

Multi-Framework Evidence Strategy:

For each control, collect evidence once and map to all applicable frameworks:

1. Policy Document — Covers SOC 2, ISO 27001, HIPAA, GDPR (one policy, multiple mappings) 2. Technical Configuration — Screenshot/export showing control is active (maps to all technical frameworks) 3. Audit Log — Proves ongoing compliance (SOC 2, PCI-DSS, HIPAA all require audit trails) 4. Review Record — Quarterly review minutes satisfy multiple framework requirements simultaneously

---

Audit Workflows, Scoring & Success Criteria

Step-by-step audit workflows, pre/post-audit validation checklists, the severity-weighted scoring methodology, and success criteria. Read this when planning or executing an audit engagement and interpreting scores.

Workflows

Workflow 1: Full Infrastructure Audit

1. Prepare inventory → Document all cloud accounts, domains, endpoints, services
2. Run infra_audit_runner.py → Generate findings across all 11 domains
3. Triage findings → Prioritize Critical > High > Medium > Low
4. Map to frameworks → Identify which framework requirements are met/unmet
5. Create remediation plan → Assign owners, set deadlines by severity SLA
6. Execute remediation → Fix Critical within 24h, High within 72h
7. Re-audit → Verify fixes, update compliance evidence
8. Generate report → Executive summary + detailed findings + evidence

Severity SLAs:

Workflow 2: DNS Security Assessment

1. Enumerate domains → Primary + all subdomains
2. Run dns_security_checker.py → Check SPF, DKIM, DMARC, DNSSEC, CAA, MTA-STS
3. Validate email chain → SPF → DKIM → DMARC alignment
4. Check domain security → Registrar lock, 2FA, WHOIS, expiration
5. Subdomain audit → Check for dangling CNAME records (takeover risk)
6. Generate DNS report → Findings + remediation DNS records

Workflow 3: Access Control Review

1. Export IdP configuration → Users, groups, roles, policies
2. Run access_control_auditor.py → Check MFA, SSO, RBAC, PAM, service accounts
3. Verify MFA coverage → Must be 100%, flag any exceptions
4. Review privileged access → Who has admin? Is JIT in place?
5. Check service accounts → Rotation, ownership, permissions
6. Access recertification → Verify all access is current and justified
7. Generate access report → Gaps + remediation steps

Workflow 4: Continuous Compliance Monitoring

1. Schedule automated scans → Weekly infra audit, daily DNS check
2. Track compliance score trends → Score per domain over time
3. Alert on regressions → Score drop or new Critical finding triggers alert
4. Quarterly full audit → Manual review + automated scan
5. Annual certification preparation → Compile evidence for auditors

---

Validation Checkpoints

Pre-Audit Validation

• [ ] Infrastructure inventory is complete and current
• [ ] All cloud accounts identified and accessible
• [ ] Domain list verified (primary + all active subdomains)
• [ ] Endpoint MDM reports available
• [ ] IdP configuration export available
• [ ] Previous audit findings reviewed

Post-Audit Validation

• [ ] All 11 domains audited with no skipped checks
• [ ] Every finding has severity, framework mapping, and remediation
• [ ] Critical and High findings have assigned owners
• [ ] Compliance score calculated per domain and overall
• [ ] Executive summary prepared
• [ ] Evidence package compiled for applicable frameworks
• [ ] Remediation deadlines set per severity SLA

---

Scoring Methodology

Each audit domain is scored 0-100 based on the controls assessed:

Score Calculation:

Domain Score = (Passed Controls * Weight) / (Total Controls * Weight) * 100

Weights by severity:
  Critical = 10
  High = 5
  Medium = 2
  Low = 1
  Info = 0 (informational, not scored)

Overall Score:

Overall Score = Weighted Average of Domain Scores

Domain Weights:
  Cloud Infrastructure: 15%
  Access Control: 15%
  Network Security: 12%
  Secrets Management: 10%
  Logging/Monitoring: 10%
  CI/CD Pipeline: 8%
  Container/K8s: 8%
  Endpoint Security: 7%
  TLS/SSL: 5%
  DNS Security: 5%
  Physical Security: 5%

Score Interpretation:

---

Success Criteria

• Overall infrastructure score of 80+ (Good or Excellent) -- indicating audit-readiness with only minor gaps across all 11 domains
• Zero Critical findings across all domains -- all Critical-severity controls (root MFA, no wildcard IAM policies, encryption at rest, hardware key admin MFA) passing
• Framework-specific compliance above 85% -- for each targeted compliance framework (SOC 2, ISO 27001, PCI-DSS, etc.), the mapped controls show 85%+ pass rate
• DNS security fully configured -- SPF, DKIM, and DMARC (policy=reject) records validated, DNSSEC enabled, CAA records set, and MTA-STS deployed
• Access control audit passes all Critical and High controls -- centralized IdP deployed, SSO integrated for all applications, hardware security keys enforced for admin accounts, PAM implemented, and RBAC documented
• Secrets management score above 90% -- dedicated secrets vault deployed, automated rotation configured, no secrets in source code (git scanning enabled), and HSM for cryptographic operations
• Evidence artifacts generated for audit -- JSON or markdown reports suitable for auditor review, with per-control pass/fail status and framework mapping

Cloud Security Baseline Reference

Comprehensive security baselines for AWS, Azure, and GCP aligned with CIS Benchmarks and compliance framework requirements.

---

AWS Security Baseline

CIS AWS Foundations Benchmark v3.0 Summary

The CIS AWS Foundations Benchmark provides prescriptive guidance for configuring security options in AWS. The following summarizes the most impactful controls.

1. Identity and Access Management

1.1 Root Account Security

Required Configuration:
- MFA enabled on root account (hardware MFA strongly preferred)
- No access keys on root account
- Root account used only for account-level operations
- Security contact configured on root account
- AWS Organizations SCP restricts root usage

Root account checklist:

• [ ] Hardware MFA (YubiKey or AWS-compatible TOTP device)
• [ ] Zero access keys (delete any existing keys)
• [ ] Contact information current (email + phone)
• [ ] Root activity triggers CloudWatch alarm
• [ ] Root API usage tracked via CloudTrail

1.2 IAM Users and Policies

Required Configuration:
- No wildcard permissions (Action:* Resource:*)
- MFA required for all IAM users
- Password policy: 14+ chars, complexity, 90-day expiry
- Unused credentials disabled (>90 days inactive)
- Access keys rotated every 90 days
- IAM Access Analyzer enabled
- No inline policies (use managed policies)

Example IAM password policy (CLI):

aws iam update-account-password-policy \
  --minimum-password-length 14 \
  --require-symbols \
  --require-numbers \
  --require-uppercase-characters \
  --require-lowercase-characters \
  --allow-users-to-change-password \
  --max-password-age 90 \
  --password-reuse-prevention 24

1.3 IAM Roles and Trust Policies

Best Practices:
- Use roles (not users) for applications and services
- External ID required for cross-account roles
- Condition keys restrict by source IP, VPC, or MFA
- Role session duration limited (1h for sensitive roles)
- Regular review of trust policies

Example trust policy with external ID:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::ACCOUNT-ID:root"},
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "unique-external-id"
      }
    }
  }]
}

2. Storage Security

2.1 S3 Bucket Security

Required Configuration:
- Account-level Block Public Access: ALL four settings enabled
- Bucket-level Block Public Access: ALL four settings enabled
- Default encryption: SSE-S3 minimum, SSE-KMS preferred
- Versioning enabled for data buckets
- Access logging enabled
- Lifecycle policies for cost and compliance
- MFA Delete for critical buckets
- S3 Object Lock for compliance (WORM)

Enable account-level block public access:

aws s3control put-public-access-block \
  --account-id $ACCOUNT_ID \
  --public-access-block-configuration \
    "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

Enable default encryption:

aws s3api put-bucket-encryption \
  --bucket my-bucket \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:region:account:key/key-id"
      },
      "BucketKeyEnabled": true
    }]
  }'

3. Networking

3.1 VPC Security

Required Configuration:
- VPC Flow Logs enabled (ALL traffic, sent to CloudWatch or S3)
- Default security group: deny all inbound, deny all outbound
- No security groups allow 0.0.0.0/0 on SSH (22) or RDP (3389)
- Private subnets for databases, application tiers
- VPC endpoints for AWS services (avoid public internet)
- NACLs as defense-in-depth (not primary control)

Enable VPC Flow Logs:

aws ec2 create-flow-logs \
  --resource-type VPC \
  --resource-ids vpc-12345678 \
  --traffic-type ALL \
  --log-destination-type cloud-watch-logs \
  --log-group-name vpc-flow-logs \
  --deliver-logs-permission-arn arn:aws:iam::ACCOUNT:role/flow-logs-role

3.2 Security Group Best Practices

Rules:
- Default deny (no rules = deny)
- Source restrictions: specific IPs or security groups, never 0.0.0.0/0 for admin ports
- Protocol-specific rules (not "all traffic")
- Description on every rule (business justification)
- Regular review (quarterly minimum)

4. Logging and Monitoring

4.1 CloudTrail

Required Configuration:
- Multi-region trail enabled
- Log file validation enabled
- S3 bucket access logging enabled for CloudTrail bucket
- CloudTrail integrated with CloudWatch Logs
- KMS encryption for CloudTrail logs
- S3 bucket policy prevents public access

Create multi-region trail:

aws cloudtrail create-trail \
  --name organization-trail \
  --s3-bucket-name cloudtrail-logs-bucket \
  --is-multi-region-trail \
  --enable-log-file-validation \
  --kms-key-id arn:aws:kms:region:account:key/key-id \
  --include-global-service-events

4.2 CloudWatch Alarms (CIS Required)

Create alarms for these events:

• Unauthorized API calls
• Console sign-in without MFA
• Root account usage
• IAM policy changes
• CloudTrail configuration changes
• S3 bucket policy changes
• Security group changes
• NACL changes
• Network gateway changes
• Route table changes
• VPC changes
• AWS Organizations changes
• Failed console sign-ins (>3 in 5 min)

4.3 GuardDuty

Required Configuration:
- Enabled in all active regions
- S3 protection enabled
- EKS protection enabled (if using EKS)
- Malware protection enabled
- Findings exported to Security Hub
- High/Critical findings trigger SNS notification

4.4 AWS Config

Required Configuration:
- Enabled in all active regions
- Recording all resource types
- Conformance packs deployed (CIS Benchmark, SOC 2)
- Non-compliant resources trigger remediation

5. Encryption and Key Management

5.1 KMS

Required Configuration:
- Customer-managed keys (CMK) for sensitive data
- Annual key rotation enabled
- Key policies follow least privilege
- Key aliases for identification
- Cross-account key sharing uses grants (not key policies)
- Key deletion requires 30-day waiting period

Enable key rotation:

aws kms enable-key-rotation --key-id $KEY_ID

5.2 RDS Encryption

Required Configuration:
- Encryption at rest enabled (KMS)
- SSL/TLS connections enforced (parameter: rds.force_ssl = 1)
- Automated backups with 7+ day retention
- Multi-AZ for production
- Not publicly accessible
- Enhanced monitoring enabled
- Deletion protection enabled
- IAM authentication enabled (where supported)

---

Azure Security Baseline

CIS Azure Foundations Benchmark v2.1 Summary

1. Identity and Access Management

1.1 Azure AD / Entra ID

Required Configuration:
- Security Defaults enabled (if no Conditional Access)
- Maximum 5 Global Administrator accounts
- All Global Admins have MFA (phishing-resistant preferred)
- Conditional Access policies configured:
  - Require MFA for all users
  - Block legacy authentication
  - Require compliant device for sensitive apps
  - Require approved client apps
- Privileged Identity Management (PIM) enabled
  - JIT activation for admin roles
  - Approval required for Global Admin activation
  - Maximum activation duration: 4 hours
- Guest user access restricted
- Self-service password reset configured with MFA

1.2 Conditional Access (Key Policies)

2. Security Center and Defender

Required Configuration:
- Microsoft Defender for Cloud enabled (all plans):
  - Defender for Servers (Plan 2)
  - Defender for App Service
  - Defender for SQL
  - Defender for Storage
  - Defender for Key Vault
  - Defender for Containers
  - Defender for DNS
- Secure Score monitored (target: 80%+)
- Auto-provisioning enabled for agents
- Security contacts configured (email + phone)
- Alert severity notifications: High and Critical

3. Storage Accounts

Required Configuration:
- Secure transfer required (HTTPS only)
- Public access disabled
- Customer-managed keys for sensitive data
- Soft delete enabled (14+ days)
- Infrastructure encryption enabled
- Shared Access Signature (SAS) expiry: maximum 1 hour
- Private endpoints for PaaS access
- Storage Analytics logging enabled
- Firewall: deny by default, allow by VNet/IP

4. Networking

Required Configuration:
- NSG rules: deny all inbound by default, allow by exception
- NSG flow logs enabled (Version 2, retention 90+ days)
- Azure Firewall or NVA deployed
- DDoS Protection Standard for public IPs
- Private endpoints for PaaS services
- Network Watcher enabled in all regions
- No NSG allows any/any inbound
- No NSG allows 0.0.0.0/0 on SSH (22) or RDP (3389)

5. Key Vault

Required Configuration:
- RBAC authorization (not legacy access policies)
- Soft delete enabled (90 days)
- Purge protection enabled
- Diagnostic logging enabled
- Firewall: allow from specific VNets/IPs only
- Key rotation policy configured
- Private endpoint for access
- Certificate auto-renewal configured

6. Monitoring

Required Configuration:
- Activity Log alerts for:
  - Create/update/delete NSG
  - Create/update/delete NSG rule
  - Create/update/delete security solution
  - Create/update/delete SQL Server firewall rule
  - Create/update policy assignment
  - Create/update/delete public IP
- Diagnostic settings on all resources
- Log Analytics workspace with 365+ day retention
- Microsoft Sentinel deployed (SIEM)
- Azure Policy assignments enforcing compliance

---

GCP Security Baseline

CIS GCP Foundations Benchmark v3.0 Summary

1. Identity and Access Management

Required Configuration:
- Organization-level policies use groups (not individual users)
- No service accounts with Owner or Editor roles
- User-managed service account keys rotate every 90 days
- Workload Identity for GKE (no service account keys)
- Domain-restricted sharing via Organization Policy
- Essential Contacts configured for Security notifications
- Service Account Key creation disabled via Organization Policy (use Workload Identity)

Organization Policy constraints:

constraints/iam.disableServiceAccountKeyCreation: true
constraints/iam.allowedPolicyMemberDomains: ["C0xxxxxxx"]

2. Logging and Monitoring

Required Configuration:
- Cloud Audit Logs enabled for all services:
  - Admin Activity (always on, no charge)
  - Data Access logs enabled for sensitive services
  - System Event logs (always on)
- Log sinks to Cloud Storage or BigQuery for retention
- Log-based metrics for:
  - Project ownership changes
  - Audit configuration changes
  - Custom role changes
  - VPC network changes
  - Firewall rule changes
  - Route changes
  - Network changes
  - Storage IAM changes
  - SQL instance configuration changes
- Alert policies for all log-based metrics

3. Networking

Required Configuration:
- Default network deleted
- VPC Flow Logs enabled for all subnets (sample rate 100%)
- Firewall rules: no 0.0.0.0/0 on SSH (22) or RDP (3389)
- Private Google Access enabled for private subnets
- VPC Service Controls for sensitive projects
- Cloud Armor WAF for public services
- Cloud DNS DNSSEC enabled
- SSL policies enforce TLS 1.2+ with MODERN profile

Firewall audit query (gcloud):

gcloud compute firewall-rules list \
  --filter="sourceRanges:0.0.0.0/0 AND (allowed.ports:22 OR allowed.ports:3389)" \
  --format="table(name,network,sourceRanges,allowed)"

4. Cloud Storage

Required Configuration:
- Uniform bucket-level access enabled
- Public access prevention enforced (organization policy)
- Customer-managed encryption keys (CMEK) for sensitive data
- Object versioning enabled
- Access logging enabled
- Retention policy for compliance data
- No allUsers or allAuthenticatedUsers in bucket IAM

Organization Policy:

constraints/storage.publicAccessPrevention: enforced
constraints/storage.uniformBucketLevelAccess: true

5. Compute and GKE

Required Configuration:
- Compute instances:
  - No default service account
  - No external IP (use NAT or IAP)
  - Shielded VM enabled
  - OS Login enabled
  - Serial port disabled
- GKE:
  - Private cluster (no public endpoint, or authorized networks)
  - Workload Identity enabled
  - Shielded Nodes enabled
  - Node auto-upgrade enabled
  - Container-Optimized OS for nodes
  - Network Policies enabled
  - Binary Authorization enabled
  - Release channel: Regular or Stable

6. Security Command Center

Required Configuration:
- SCC Premium enabled
- Web Security Scanner enabled
- Event Threat Detection enabled
- Container Threat Detection enabled
- Security Health Analytics enabled
- Findings exported to SIEM
- High/Critical findings trigger notifications

---

Cross-Cloud Security Comparison

---

Minimum Viable Security Baseline (Any Cloud)

For organizations just starting, implement these controls first:

Tier 1 — Immediate (Week 1)

1. Enable MFA for all accounts (hardware keys for admins) 2. Enable audit logging in all regions 3. Block public access to storage (S3/Storage/GCS) 4. Remove wildcard permissions from IAM 5. Enable encryption at rest for databases 6. No open SSH/RDP to the internet

Tier 2 — Short-term (Month 1)

1. Deploy cloud security posture management (CSPM) 2. Enable VPC/NSG flow logs 3. Configure alerting for security events 4. Enable vulnerability scanning 5. Implement network segmentation 6. Deploy WAF for public applications

Tier 3 — Medium-term (Quarter 1)

1. Implement least-privilege IAM (review all policies) 2. Deploy SIEM with correlation rules 3. Enable container image scanning 4. Implement secrets management 5. Configure key rotation 6. Establish quarterly access reviews

---

Last Updated: March 2026 CIS Benchmark Versions: AWS v3.0, Azure v2.1, GCP v3.0

Compliance Framework Mapping Reference

Master mapping of infrastructure security controls to compliance frameworks. Use this to satisfy multiple framework requirements with single control implementations.

---

Supported Frameworks

---

Master Control Mapping Table

Access Control

Encryption

Network Security

Logging and Monitoring

Endpoint Security

CI/CD and Supply Chain

Secrets Management

Physical Security

---

Control Overlap Analysis

Highest-Overlap Controls (Implement First)

These controls satisfy the most frameworks simultaneously:

Framework-Specific Controls (Low Overlap)

These controls are required by only 1-2 frameworks:

---

Prioritization Guide for Multi-Framework Compliance

If pursuing SOC 2 + ISO 27001 (most common combination)

Overlap: ~85% — Most SOC 2 controls map directly to ISO 27001 Annex A controls.

Implementation order: 1. Access control (IdP, SSO, MFA, RBAC) — satisfies CC6.1-CC6.3 + A.5.15-A.8.5 2. Encryption (at rest + in transit) — satisfies CC6.7 + A.8.24 3. Logging and monitoring — satisfies CC7.2 + A.8.15-A.8.16 4. Change management (CI/CD security) — satisfies CC7.1 + A.8.25 5. Vendor management — satisfies CC9.2 + A.5.19-A.5.21 6. Incident response — satisfies CC7.3-CC7.4 + A.5.24-A.5.28 7. Physical security — satisfies CC6.4-CC6.5 + A.7.1-A.7.14

If pursuing SOC 2 + HIPAA (healthcare SaaS)

Overlap: ~70% — HIPAA has specific PHI requirements beyond SOC 2.

Additional HIPAA-specific: 1. PHI inventory and data flow mapping 2. Business Associate Agreements (BAAs) 3. Minimum necessary standard (data minimization) 4. Patient rights (access, amendment, accounting) 5. Breach notification (60 days to HHS, individuals) 6. Risk analysis (annual, documented) 7. Contingency plan (emergency mode, disaster recovery)

If pursuing SOC 2 + PCI-DSS (fintech/payments)

Overlap: ~60% — PCI-DSS has prescriptive requirements beyond SOC 2.

Additional PCI-DSS-specific: 1. Cardholder Data Environment (CDE) scoping and isolation 2. Quarterly ASV (Approved Scanning Vendor) scans 3. Annual penetration testing 4. PAN (Primary Account Number) masking/tokenization 5. Key management lifecycle (custodians, split knowledge) 6. Wireless scanning (quarterly) 7. Service provider management (PCI compliance verification)

If pursuing NIS2 + DORA (EU critical infrastructure + financial)

Overlap: ~75% — DORA is more prescriptive than NIS2.

Combined requirements: 1. ICT risk management framework 2. Incident reporting (NIS2: 24h early warning, 72h full; DORA: 4h initial, 72h intermediate) 3. Resilience testing (DORA: TLPT for significant entities) 4. Supply chain security (both) 5. Business continuity and DR 6. Board-level accountability

---

Evidence Collection Strategy

Single-Evidence, Multi-Framework Approach

For each control, collect ONE evidence artifact that satisfies ALL applicable frameworks:

Evidence Collection Calendar

---

Framework-Specific Quick Reference

SOC 2 Trust Services Criteria (Most Common)

ISO 27001:2022 Annex A Control Families

NIST CSF 2.0 Functions

---

Last Updated: March 2026 Frameworks Covered: 10 (SOC 2, ISO 27001, HIPAA, GDPR, PCI-DSS, NIS2, DORA, NIST CSF, FedRAMP, CCPA) Total Control Mappings: 250+