@open-agreements/open-agreements 0.2.0 → 0.2.2

package/skills/iso-27001-internal-audit/CONNECTORS.md

@@ -0,0 +1,23 @@
+# Connectors
+
+## How tool references work
+
+This skill uses `~~category` placeholders for optional integrations. The skill works without any connectors configured — they enhance the experience when available.
+
+## Connectors for this skill
+
+| Category | Placeholder | Recommended server | Other options |
+|----------|-------------|-------------------|---------------|
+| Compliance data | `~~compliance` | Compliance MCP server (planned — not yet available) | Local `compliance/` directory files |
+
+### Local compliance data (current default)
+
+If the `compliance/` directory exists with status and evidence files, the skill reads those directly. No MCP server needed — just ensure `compliance/status/last_refresh.yaml` is current.
+
+### Compliance MCP server (planned)
+
+A dedicated compliance MCP server with live test results, evidence freshness tracking, and real-time gap analysis is planned but not yet available. When released, it will be installable as a standard MCP server. Until then, the skill operates in local-data or reference-only mode.
+
+### Fallback: Reference only
+
+Without any connector, the skill uses embedded `rules/` files for procedural guidance, control descriptions, and evidence checklists. No organization-specific status data is available in this mode.

package/skills/iso-27001-internal-audit/SKILL.md

@@ -0,0 +1,272 @@
+---
+name: iso-27001-internal-audit
+description: >-
+  Run an ISO 27001 internal audit. Walk through controls by domain, identify
+  gaps, collect evidence, and generate findings with corrective action
+  recommendations. Uses NIST SP 800-53 (public domain) as canonical reference.
+license: MIT
+compatibility: >-
+  Works with any AI agent. Enhanced with compliance MCP server for live
+  dashboard data. Falls back to embedded reference files when no live data
+  is available.
+metadata:
+  author: open-agreements
+  version: "0.1.0"
+  frameworks:
+    - ISO 27001:2022
+    - SOC 2 Type II
+    - NIST SP 800-53 Rev 5
+---
+
+# ISO 27001 Internal Audit
+
+Run a structured internal audit against ISO 27001:2022. This skill walks you through scoping, control assessment, evidence collection, and findings generation — following the same workflow a certified auditor uses.
+
+## Security Model
+
+- **No scripts executed** — this skill is markdown-only procedural guidance
+- **No secrets required** — works with public reference data
+- **IP-clean** — all control descriptions are original writing referencing NIST SP 800-53 (public domain). ISO 27001:2022 controls are referenced by section ID only (e.g., "A.5.15"), never by copyrighted title or description
+- **Evidence stays local** — all evidence collection commands output to local filesystem
+
+## When to Use
+
+Activate this skill when:
+
+1. **Preparing for a surveillance or certification audit** — run 4-6 weeks before the external audit
+2. **Performing quarterly internal audit** — ISO 27001 requires at least annual internal audits; quarterly is best practice
+3. **Post-incident review** — assess whether controls failed and what corrective actions are needed
+4. **New framework adoption** — map existing controls to ISO 27001 requirements
+5. **Onboarding a new compliance tool** — validate that automated checks cover the right controls
+
+Do NOT use for:
+- Generating the ISO 27001 Statement of Applicability (SoA) from scratch — use `iso-27001-evidence-collection` for evidence gathering first
+- SOC 2-only audits — use `soc2-readiness` instead
+- Reading or interpreting a specific contract clause — use legal agreement skills
+
+## Core Concepts
+
+### Control Domains (ISO 27001:2022 Annex A)
+
+ISO 27001:2022 has 93 Annex A controls across 4 domains, plus ISMS clauses 4-10 (30 sub-clauses). This skill covers **48 priority Annex A controls** (of 93 total) — the most critical per domain for cloud-native startups. Remaining controls are lower-tier or typically N/A for cloud-native organizations.
+
+| Domain | Controls | Focus |
+|--------|----------|-------|
+| A.5 Organizational | 37 | Policies, roles, incident management, supplier relations |
+| A.6 People | 8 | Screening, training, termination, confidentiality |
+| A.7 Physical | 14 | Facility security, equipment, media — mostly N/A for cloud startups |
+| A.8 Technological | 34 | Access control, crypto, logging, SDLC, network security |
+| Clauses 4-10 | 30 | ISMS management system (context, leadership, planning, support, operation, performance, improvement) |
+
+### Decision Tree: Startup Scoping
+
+```
+Is the organization cloud-native (no owned data centers)?
+├── YES → Mark A.7.1-A.7.9, A.7.11-A.7.13 as "satisfied by cloud provider SOC 2"
+│         Focus evidence on: laptops, home offices, mobile devices
+├── NO  → Full A.7 assessment required
+│
+Does the organization develop software?
+├── YES → A.8.25-A.8.34 (SDLC controls) are in scope
+├── NO  → A.8.25-A.8.34 can be scoped out with justification
+│
+Does the organization handle PII?
+├── YES → A.5.34 (privacy) is critical, cross-reference with GDPR/CCPA
+├── NO  → A.5.34 is checkbox tier
+```
+
+### Control Tiering
+
+Not all 93 controls fail equally. Prioritize by audit failure frequency:
+
+| Tier | Count | Treatment |
+|------|-------|-----------|
+| **Critical** | ~30 | Full assessment: evidence, interviews, observation |
+| **Relevant** | ~30 | Standard check: evidence review, spot-check |
+| **Checkbox** | ~33 | Verify policy exists or cloud provider covers it |
+
+For detailed per-control guidance, load `rules/<domain>.md`.
+
+## Step-by-Step Workflow
+
+### Step 1: Scope and Context
+
+1. **Identify the ISMS scope** — What systems, processes, locations, and people are in scope?
+2. **Gather the Statement of Applicability (SoA)** — Which of the 93 Annex A controls apply?
+3. **Review previous audit findings** — What was flagged last time? Are corrective actions closed?
+4. **Check data freshness** — If using a monitoring dashboard or automated testing system, verify data is < 7 days old
+
+```
+# If compliance MCP is available:
+check_compliance_status(framework="iso27001_2022")
+
+# If reading local files:
+# Check compliance/status/last_refresh.yaml for staleness
+```
+
+### Step 2: ISMS Clause Assessment (Clauses 4-10)
+
+Most startups fail here — they treat ISMS as documentation, not a functioning management system.
+
+1. **Clause 5 (Leadership)** — Is there a signed security policy? Who is the ISMS owner? Is there evidence of management review?
+2. **Clause 6 (Planning)** — Is there a risk assessment? Is it current (< 12 months)? Does it reference the SoA?
+3. **Clause 7 (Support)** — Is there a competence matrix? Are training records current?
+4. **Clause 8 (Operation)** — Is the risk treatment plan being executed?
+5. **Clause 9 (Performance)** — Are there metrics? Has an internal audit been done? Is there a management review record?
+6. **Clause 10 (Improvement)** — Are nonconformities tracked? Are corrective actions implemented?
+
+**Auditor hint**: Auditors look for a CONNECTED chain — risk assessment → SoA → risk treatment plan → evidence of implementation → monitoring → management review → improvement. Any break in the chain is a nonconformity.
+
+### Step 3: Annex A Control Assessment
+
+Work through controls by domain, prioritizing Critical tier:
+
+1. **For each Critical control**:
+   - Check: Is there a documented policy/procedure?
+   - Check: Is there evidence of implementation?
+   - Check: Is there evidence of monitoring/review?
+   - Record finding: Conformity / Minor nonconformity / Major nonconformity / Observation
+
+2. **For each Relevant control**:
+   - Check: Is there evidence of implementation?
+   - Spot-check one or two items
+   - Record finding
+
+3. **For each Checkbox control**:
+   - Verify policy exists or cloud provider SOC 2 covers it
+   - Record as conforming or note exception
+
+```
+# If compliance MCP is available:
+get_domain_overview(domain="organizational")
+get_control_guidance(control_id="A.5.15")
+list_evidence_gaps(framework="iso27001_2022", tier="critical")
+```
+
+### Step 4: Evidence Collection
+
+For each finding, collect supporting evidence:
+
+1. **API exports** (preferred) — timestamped JSON/CSV from source systems
+2. **Screenshots** (when API unavailable) — must include visible system clock
+3. **Interview notes** — summarize who said what, when
+4. **Document review** — note document name, version, date reviewed
+
+**Evidence naming convention**: `{control_id}_{evidence_type}_{date}.{ext}`
+Example: `A.5.15_user-access-list_2026-02-28.json`
+
+For detailed collection commands, load `rules/` files or use the `iso-27001-evidence-collection` skill.
+
+### Step 5: Generate Findings
+
+For each nonconformity:
+
+```markdown
+## Finding: [Short title]
+
+- **Control**: A.x.x
+- **NIST Reference**: [NIST control ID]
+- **Severity**: Major / Minor / Observation
+- **Description**: [What was found]
+- **Evidence**: [What evidence supports the finding]
+- **Root Cause**: [Why the control failed]
+- **Corrective Action**: [Specific remediation steps]
+- **Due Date**: [Agreed timeline]
+- **Owner**: [Person responsible]
+```
+
+**Severity definitions**:
+- **Major nonconformity**: Control is missing or completely ineffective. Audit failure risk.
+- **Minor nonconformity**: Control exists but has gaps. Must fix before next surveillance audit.
+- **Observation**: Potential improvement. Not required but recommended.
+
+### Step 6: Audit Report
+
+Generate a structured audit report:
+
+1. **Executive summary** — overall ISMS maturity, key findings, recommendation
+2. **Scope** — what was audited, what was excluded
+3. **Methodology** — controls assessed, evidence reviewed, people interviewed
+4. **Findings** — grouped by domain, with severity and corrective actions
+5. **Positive observations** — what's working well (auditors do note these)
+6. **Conclusion** — readiness for external audit, recommended timeline
+
+## Quick Reference: Top 10 Controls That Fail Most Often
+
+| # | Control | Common Failure | Fix |
+|---|---------|---------------|-----|
+| 1 | A.5.15 | No periodic access review | Schedule quarterly reviews, export user lists |
+| 2 | A.8.8 | No vulnerability scanning | Deploy Dependabot/Snyk, schedule infra scans |
+| 3 | A.5.24 | Incident response plan untested | Run tabletop exercise, document results |
+| 4 | A.8.5 | MFA not enforced everywhere | Enable MFA on all production + admin accounts |
+| 5 | A.5.30 | No business continuity test | Run DR failover test, document RTO/RPO results |
+| 6 | A.8.15 | Audit logs not centralized | Ship logs to SIEM/CloudWatch/Stackdriver |
+| 7 | A.8.9 | No baseline configuration | Document server/container base images |
+| 8 | A.6.1 | Background checks incomplete | Verify all employees have completed screening |
+| 9 | A.8.32 | No change management process | Require PR reviews, document deployment process |
+| 10 | A.5.9 | Asset inventory incomplete | Export from cloud provider + endpoint management |
+
+## DO / DON'T
+
+### DO
+- Collect evidence via API exports with ISO 8601 timestamps — always preferred over screenshots
+- Test controls, don't just review documentation — auditors check implementation, not just policies
+- Interview people at different levels — manager says one thing, engineer may say another
+- Document positive findings — shows the audit is balanced and thorough
+- Keep the SoA aligned with actual controls — gaps between SoA and implementation are major findings
+- Use `screencapture -x ~/evidence/{filename}.png` on macOS when screenshots are necessary
+
+### DON'T
+- Screenshot portals without visible system clock — auditors will reject undated evidence
+- Accept "we have a policy" without checking implementation — "show me" > "tell me"
+- Audit your own work — independence requirement (Clause 9.2) means auditors can't audit their own area
+- Treat checkbox controls as zero-effort — even N/A controls need justification in the SoA
+- Skip ISMS clauses to focus only on Annex A — most first-time failures are in clauses 4-10
+
+## Troubleshooting
+
+| Problem | Solution |
+|---------|----------|
+| Data is stale (> 7 days old) | Refresh from monitoring dashboard or re-export from source systems |
+| Can't determine which controls apply | Start with the SoA; if no SoA exists, use the decision tree above |
+| Too many findings to address before audit | Prioritize: fix all Major nonconformities first, then Critical-tier Minors |
+| Evidence timestamps don't match audit period | Re-collect evidence within the audit window (typically 12 months) |
+| Cloud provider controls not documented | Request SOC 2 Type II report from provider; map their controls to your SoA |
+| Internal audit has never been done | This IS the first internal audit — document that in the report and plan for regular cadence |
+
+## Rules
+
+For detailed per-control guidance, load the appropriate rules file:
+
+| File | Coverage |
+|------|----------|
+| `rules/access-control.md` | A.5.15-A.5.18, A.8.2-A.8.5 — identity, authentication, authorization |
+| `rules/incident-response.md` | A.5.24-A.5.29, A.6.8 — incident lifecycle |
+| `rules/encryption.md` | A.8.24, A.8.10-A.8.12 — cryptographic controls |
+| `rules/change-management.md` | A.8.25-A.8.34, A.8.9, A.8.32 — SDLC and configuration |
+| `rules/logging-monitoring.md` | A.8.15-A.8.17 — audit trails and monitoring |
+| `rules/business-continuity.md` | A.5.30, A.8.13-A.8.14 — backup, DR, BCP |
+| `rules/people-controls.md` | A.6.1-A.6.8 — HR security lifecycle |
+| `rules/supplier-management.md` | A.5.19-A.5.23 — third-party risk |
+| `rules/isms-management.md` | Clauses 4-10 — management system operation |
+
+## Attribution
+
+Audit procedures and control guidance developed with [Internal ISO Audit](https://internalisoaudit.com) (Hazel Castro, ISO 27001 Lead Auditor, 14+ years, 100+ audits).
+
+## Runtime Detection
+
+This skill operates in three modes, detected automatically:
+
+1. **Compliance MCP server available** (best) — Live dashboard data, automated test results, real-time gap analysis
+   - Detected by: `check_compliance_status()` returns data
+   - Benefits: Current test pass/fail status, evidence freshness, SLA tracking
+
+2. **Local compliance data available** (good) — Reads `compliance/` directory directly
+   - Detected by: `compliance/status/last_refresh.yaml` exists
+   - Benefits: Historical test data, evidence status, control mappings
+
+3. **Reference only** (baseline) — Uses embedded `rules/` files, no live data
+   - Always available
+   - Benefits: Procedural guidance, control descriptions, evidence checklists
+   - Limitation: No organization-specific status data

package/skills/iso-27001-internal-audit/rules/access-control.md

@@ -0,0 +1,191 @@
+# Access Control Rules
+
+Per-control audit guidance for identity, authentication, and authorization controls.
+
+## A.5.15 — Access Control Policy & Enforcement
+
+**Tier**: Critical | **NIST**: AC-1, AC-2, AC-3, AC-6
+
+Ensure access to information and systems is restricted based on business and security requirements. The access control policy should define rules for granting, reviewing, and revoking access based on the principle of least privilege.
+
+**Auditor hints**:
+- Auditors want to see the access control POLICY and evidence it's being FOLLOWED — not just that a policy document exists
+- They'll sample 3-5 joiners and 3-5 leavers to verify access was provisioned/revoked correctly
+- Look for: quarterly access reviews with documented decisions (retain/revoke), not just screenshots of user lists
+- Common gap: policy says "least privilege" but admin accounts are used for daily work
+
+**Evidence collection**:
+```bash
+# GitHub org members and roles
+gh api orgs/{org}/members --paginate | jq '.[] | {login, role: .role}'
+
+# GCP IAM bindings
+gcloud projects get-iam-policy {project} --format=json | jq '.bindings'
+
+# Azure role assignments
+az role assignment list --all --output json
+
+# Google Workspace users
+gam print users fields name,email,orgUnitPath,suspended,isAdmin
+```
+
+**Startup pitfalls**:
+- Using shared accounts ("the deploy key") instead of individual credentials
+- No documented process for access requests — "just Slack the admin" isn't auditable
+- Access reviews never done or done once then abandoned
+
+---
+
+## A.5.16 — Identity Management
+
+**Tier**: Critical | **NIST**: AC-2, IA-2, IA-4, IA-8, IA-12
+
+Manage the full lifecycle of identities — from provisioning through changes to deprovisioning. Each person should have a unique identity; shared/generic accounts should be documented exceptions.
+
+**Auditor hints**:
+- Auditors check for unique user IDs — generic accounts like "admin@" or "deploy@" are flags
+- They'll look for identity lifecycle evidence: joiner provisioning, mover role changes, leaver deprovisioning
+- Service accounts count as identities — they need owners and review cycles too
+
+**Evidence collection**:
+```bash
+# List all identities in IdP
+gam print users fields primaryEmail,name,creationTime,lastLoginTime,suspended
+
+# Service accounts (GCP)
+gcloud iam service-accounts list --format=json | jq '.[] | {email, displayName, disabled}'
+
+# GitHub service/bot accounts
+gh api orgs/{org}/members --paginate | jq '[.[] | select(.type == "Bot")]'
+```
+
+---
+
+## A.5.17 — Authentication Information
+
+**Tier**: Critical | **NIST**: IA-1, IA-5
+
+Manage authentication credentials (passwords, tokens, keys, certificates) through their lifecycle. Define minimum strength requirements and enforce MFA where available.
+
+**Auditor hints**:
+- MFA is the #1 thing auditors check — if it's not enforced on production systems and admin accounts, expect a finding
+- They'll verify password policy in the IdP matches the documented policy
+- API keys and tokens need rotation schedules — "we'll rotate if compromised" is not a policy
+- SSH keys should have expiration dates or documented rotation cadence
+
+**Evidence collection**:
+```bash
+# Google Workspace MFA enforcement
+gam print users fields primaryEmail,isEnrolledIn2Sv,isEnforcedIn2Sv
+
+# GitHub org MFA requirement
+gh api orgs/{org} | jq '{two_factor_requirement_enabled}'
+
+# Azure AD MFA status
+az ad user list --query "[].{name:displayName,mfa:strongAuthenticationDetail}" --output json
+```
+
+---
+
+## A.5.18 — Access Rights
+
+**Tier**: Critical | **NIST**: AC-2, PS-5
+
+Provision, review, modify, and revoke access rights in accordance with the access control policy. Access rights should be reviewed at regular intervals and promptly revoked when no longer needed.
+
+**Auditor hints**:
+- The "48-hour rule": auditors expect access revocation within 24-48 hours of termination, not just at the next quarterly review
+- They'll cross-reference HR termination dates with last-active dates in systems
+- Role changes (promotions, transfers) should trigger access reviews — people accumulate permissions over time
+- Look for orphaned accounts: users who left but still show as active
+
+**Evidence collection**:
+```bash
+# Cross-reference terminated users with active accounts
+# Step 1: Get terminated users from HR system (export CSV)
+# Step 2: Check against active users
+gam print users fields primaryEmail,suspended,lastLoginTime | grep -v "True"
+
+# GitHub: check for stale members
+gh api orgs/{org}/members --paginate | jq '.[] | {login, updated_at}'
+```
+
+---
+
+## A.8.2 — Privileged Access Rights
+
+**Tier**: Critical | **NIST**: AC-6
+
+Restrict and manage the allocation of privileged access rights (admin, root, superuser). Privileged access should be time-limited where possible and subject to enhanced monitoring.
+
+**Auditor hints**:
+- Auditors want a LIST of all privileged users across all systems — if you can't produce this, it's a finding
+- "Everyone is admin" is a common startup pattern and a guaranteed finding
+- Just-in-time (JIT) access is best practice but not required — having a small, documented set of admins is sufficient
+- Privileged access should have separate credentials from daily-use accounts
+
+**Evidence collection**:
+```bash
+# GCP: users with Owner/Editor roles
+gcloud projects get-iam-policy {project} --format=json | \
+  jq '.bindings[] | select(.role == "roles/owner" or .role == "roles/editor")'
+
+# GitHub: org owners
+gh api orgs/{org}/members?role=admin --paginate | jq '.[].login'
+
+# Azure: Global Admins (via MS Graph)
+az rest --method GET \
+  --url "https://graph.microsoft.com/v1.0/directoryRoles/$(az rest --method GET --url 'https://graph.microsoft.com/v1.0/directoryRoles' --query "value[?displayName=='Global Administrator'].id" -o tsv)/members" \
+  --query "value[].{displayName:displayName,upn:userPrincipalName}" -o json
+```
+
+---
+
+## A.8.3 — Information Access Restriction
+
+**Tier**: Critical | **NIST**: AC-3, AC-6
+
+Restrict access to information and application functions based on the access control policy. Systems should enforce access restrictions, not rely on user self-governance.
+
+**Auditor hints**:
+- Auditors test this by checking if users have access they shouldn't — especially cross-environment (dev accessing prod data)
+- Database access is a common gap: developers often have direct production database access "for debugging"
+- API key scoping: keys that grant broad access when narrow scope would suffice
+
+**Evidence collection**:
+```bash
+# GCP: check for overly broad IAM roles
+gcloud projects get-iam-policy {project} --format=json | \
+  jq '.bindings[] | select(.role | test("roles/(owner|editor|viewer)"))'
+
+# GitHub: repo access by team
+gh api orgs/{org}/teams --paginate | jq '.[].slug' | while read team; do
+  echo "=== $team ===" && gh api orgs/{org}/teams/$team/repos --paginate | jq '.[].name'
+done
+```
+
+---
+
+## A.8.5 — Secure Authentication
+
+**Tier**: Critical | **NIST**: AC-7, IA-2, IA-6, IA-8, SC-23
+
+Implement secure authentication mechanisms including MFA, session management, account lockout, and authentication feedback controls.
+
+**Auditor hints**:
+- MFA enforcement is non-negotiable for production and admin access
+- Session timeout should be configured (15-30 min inactive for sensitive systems)
+- Account lockout after failed attempts — check IdP configuration
+- SSO is strongly preferred over individual application passwords
+
+**Evidence collection**:
+```bash
+# Google Workspace: session control and MFA
+gam print users fields primaryEmail,isEnforcedIn2Sv
+
+# GitHub: org settings
+gh api orgs/{org} | jq '{two_factor_requirement_enabled, default_repository_permission}'
+
+# Check session timeout in cloud console (usually screenshot needed)
+# macOS: screencapture -x ~/evidence/session-config_$(date +%Y-%m-%d).png
+```

package/skills/iso-27001-internal-audit/rules/business-continuity.md

@@ -0,0 +1,94 @@
+# Business Continuity Rules
+
+Per-control audit guidance for backup, disaster recovery, and business continuity planning.
+
+## A.5.30 — ICT Readiness for Business Continuity
+
+**Tier**: Critical | **NIST**: CP-1, CP-2, CP-3, CP-4
+
+Ensure ICT systems can be recovered within required timeframes during disruption. Define RTO (Recovery Time Objective) and RPO (Recovery Point Objective) for critical systems. Test recovery procedures regularly.
+
+**Auditor hints**:
+- Auditors check THREE things: (1) BCP/DR plan exists with defined RTO/RPO, (2) the plan has been TESTED, (3) test results are documented
+- A plan tested > 12 months ago is a finding — annual testing is the minimum
+- "We use cloud so we're resilient" is not a BCP — auditors want to see that YOU tested failover, not just that your provider can
+- RTO/RPO should be defined per system based on business impact analysis, not a blanket number
+- The test should include actual recovery steps, not just "we verified the backup exists"
+
+**Evidence collection**:
+- Business continuity plan (with version date)
+- Business impact analysis (system criticality, RTO/RPO per system)
+- DR test records (date, scope, participants, results, issues found)
+- Recovery time actuals vs. RTO targets
+
+```bash
+# GCP: verify backup configuration
+gcloud sql instances describe {instance} --format="json(settings.backupConfiguration)"
+
+# Azure: check backup policy
+az backup policy list --resource-group {rg} --vault-name {vault} --output json
+
+# AWS: backup plans
+# aws backup list-backup-plans --output json
+```
+
+**Startup pitfalls**:
+- Having backups but never testing restore — a backup you can't restore from is worthless
+- No defined RTO/RPO — "as fast as possible" is not a measurable objective
+- BCP covers infrastructure but not data (database backups, secrets, configuration)
+- Single-region deployment with no failover plan
+
+---
+
+## A.8.13 — Information Backup
+
+**Tier**: Critical | **NIST**: CP-9
+
+Maintain and regularly test backup copies of information, software, and system configurations. Backups should be stored separately from primary systems and encrypted.
+
+**Auditor hints**:
+- Auditors verify: backup frequency matches RPO, backups are encrypted, backups are stored in a different location/region
+- They'll ask for a RECENT RESTORE TEST — "we restored a database in Q2" with evidence
+- Automated backups are good but auditors still want to see that someone verified they completed successfully
+- Backup alerts (failure notifications) should be configured and monitored
+
+**Evidence collection**:
+```bash
+# GCP: Cloud SQL backup history
+gcloud sql backups list --instance={instance} --format=json | jq '.[0:5]'
+
+# GCP: Cloud Storage versioning (for file backups)
+gsutil versioning get gs://{bucket}
+
+# Azure: backup job history
+az backup job list --resource-group {rg} --vault-name {vault} --output json | jq '.[0:5]'
+
+# Verify backup encryption
+gcloud sql instances describe {instance} --format="json(settings.dataDiskEncryptionConfiguration)"
+```
+
+---
+
+## A.8.14 — Redundancy of Information Processing Facilities
+
+**Tier**: Relevant | **NIST**: CP-6, CP-7, CP-10
+
+Implement sufficient redundancy in information processing facilities to meet availability requirements. This includes compute, storage, network, and power redundancy.
+
+**Auditor hints**:
+- For cloud-native startups, this is largely covered by cloud provider SLAs — but auditors want to see you've CHOSEN appropriate service tiers
+- Multi-AZ or multi-region deployment for production is expected for critical systems
+- Database replication configuration should match RTO/RPO requirements
+- Auditors may ask: "What happens if your primary region goes down?" — have an answer
+
+**Evidence collection**:
+```bash
+# GCP: check instance zones/regions
+gcloud compute instances list --format="json(name,zone,status)"
+
+# GCP: Cloud SQL HA configuration
+gcloud sql instances describe {instance} --format="json(settings.availabilityType)"
+
+# Azure: check resource distribution across regions
+az resource list --output json | jq 'group_by(.location) | .[] | {location: .[0].location, count: length}'
+```