Cloud Foundations Functional Area Runbooks Catalog¶

For CxO and engineering leads: Copy one of the two tabs below for each functional area to either execute a runbooks command directly OR invoke an autonomous command to coordinate the gap-close action.

⬇️ Where You Are Today / ⬆️ Where You're Going¶

⬇️ Multi-Org LZ — Where You Are Today⬆️ Enterprise LZ Target — Where You're Going

Current Posture (by domain): Your organization likely has partial coverage — backup policies not org-wide, patching below target, spend unattributed, guardrails advisory-only, threat detection incomplete, and network onboarding manual. Each gap represents board risk and operational toil.

Next Action: Choose one domain (recommended: Business Continuity or Operations — the two highest-velocity fixes) and execute the runbooks CLI commands below to assess today's state. Results feed the scorecard.

Target Posture (by domain): Org-wide backup coverage by design (no account escapes), patch compliance >80% by baseline, spend 100% attributed, guardrails inherited at OU level (not per-account), threat detection 100% via Control Tower, and network onboarding is template instantiation. Zero toil; continuous assurance; board-demonstrated maturity.

Timeline: 12–24 weeks for the full foundation. Business Continuity and Operations close first (8 weeks); the rest run in parallel.

Board-Risk-Weighted Continuous-Assurance Index (BRW-CAI)¶

Definition: BRW-CAI is one number (0–100%) representing your organization's cloud foundation maturity across six board-risk domains. It is calculated as:

BRW-CAI = Σ(current_maturity_stage × risk_weight) / Σ(target_stage × risk_weight)

Why it matters: The board asks "how resilient is our cloud?" This single metric answers it, vendor-agnostic and comparable across products (both CloudOps RESPOND and DevOps BUILD report to the same BRW-CAI). A BRW-CAI of 65% means you're two-thirds of the way to target; a gap of 35% translates directly to board risk and CAPEX priority.

BRW-CAI Scorecard (Your Foundation Today vs. Target)¶

Domain	Current Stage	Target Stage	Risk Weight	Gap	Owner	Board Question
Business Continuity	—	4	5	—	CSO / CEO	Can we recover every account if we're hit today?
Operations	—	4	3	—	CTO / CSO	Is our whole fleet patched to target?
Finance	—	4	3	—	CFO / CEO	Which business unit drives our cloud spend?
Governance	—	4	4	—	CDO / CEO	Are our guardrails enforced or just advisory?
Security	—	4	5	—	CSO / CTO	Is every account monitored for threats?
Infrastructure	—	4	2	—	CTO / VP-Infra	Can we onboard the next account in minutes?

How to fill the scorecard: Run the commands in the domain sections below (each tab has [A1-Discovery] / [A2-Inventory] commands). Results map to a maturity stage (0=None, 1=Manual, 2=Partial, 3=Continuous, 4=Automated). Paste your current stage into the table. The BRW-CAI dashboard will auto-calculate your gap.

One governance roof, two orderings: This RESPOND tracker (top-down, board-risk order) pairs with the DevOps BUILD tracker (bottom-up, dependency order). Both use the same six domains, same owners, same risk weights, and the same BRW-CAI north-star. The two orderings (top-down vs. bottom-up) reflect different jobs: RESPOND operates by risk priority; BUILD builds dependency-first. Unifying the governance and SSOT removes drift between the two halves. See DevOps Cloud Foundations Tracker for the companion BUILD view.

1. Business Continuity — Org-Wide Backup Coverage¶

Owner: CSO · Also: CEO · Board asks: "Can we recover every account if we're hit today?"

The Challenge: The majority of accounts lack backup coverage. AWS Backup policy is enabled at the root OU but not propagated. This is the #1 board risk.

The Value: One org backup policy write → 100% account coverage. A single policy, not a multi-account project.

🖥️ Runbooks CLI🤖 Prompts

# [A1-Discovery] Assess current backup posture across the organization
runbooks inventory collect --all-profile $AWS_OPERATIONS_PROFILE

# [A2-Inventory] Check backup vault status by account  
runbooks cfat assess --all-profile $AWS_MANAGEMENT_PROFILE

/cfat:assess

Business Value: Unrecoverable accounts represent existential risk and a board-level liability. A single org-wide backup policy propagated to all accounts moves recovery from an account-by-account gamble into a design guarantee — every new and migrated account inherits automatic vault creation. One-time policy write; permanent compliance. Ransomware and region-outage recovery timelines become measurable and cloud-resilient. Next incident, the CSO can confirm recoverable backups exist; regulatory findings (SOCI Act, AESCSF, NZISM) are prevented by design.

2. Operations — Patch Manager Baseline¶

Owner: CTO · Also: CSO · Board asks: "Is our whole fleet patched to target?"

The Challenge: Compliance is critically below target for patch-compliant account-rule instances. This is the highest operational-risk amplifier.

The Value: Patch Manager baseline in Account Factory → 80%+ compliance gate in 12 weeks.

🖥️ Runbooks CLI🤖 Prompts

# [A1-Discovery] Check patch compliance across all accounts
runbooks inventory enrich-ec2 --all-profile $AWS_OPERATIONS_PROFILE

# [A1-Investigate] Get SSM agent health per instance
runbooks inventory ssm-status --instance-id <instance-id> --profile $AWS_PROFILE

/aws:ec2-investigate

Lifecycle & Incident Operations¶

🖥️ Runbooks CLI🤖 Prompts

# [A2-Inventory] Collect lifecycle and incident data
runbooks inventory collect --all-profile $AWS_OPERATIONS_PROFILE

/itsm:lifecycle

Business Value: Critical compliance gaps expose the fastest attack vector — unpatched instances. A zero-day on one unpatched instance can pivot across the organization uncontained. Patch Manager baseline applied at the OU boundary means all instances are evaluated monthly by default; exceptions are explicit, not invisible. Continuous patch signals reduce incident-response friction and lower MTTR when a real CVE lands. At the next security incident, the CTO can prove a baseline existed. Regulatory findings on continuous patch evaluation are prevented by design.

3. Finance — Tag-Enforcement for Cost Attribution¶

Owner: CFO · Also: CEO · Board asks: "Which business unit drives our cloud spend?"

The Challenge: The majority of monthly spend is unattributed. The CFO cannot chargeback to business units.

The Value: Tag-enforcement SCP + account-vending tag policy → permanent showback clarity + 5–8% optimization opportunity.

🖥️ Runbooks CLI🤖 Prompts

# [A1-Discovery] Check tag coverage across the organization
runbooks inventory tag-coverage --all-profile $AWS_OPERATIONS_PROFILE

# [A3-FinOps] Show cost breakdown by service (with tag context)
runbooks finops dashboard --all-profile $AWS_BILLING_PROFILE

# [A2-Inventory] Validate cost-allocation tags for completeness
runbooks finops check-config-compliance --all-profile $AWS_MANAGEMENT_PROFILE

/finops:analyze

Config-Compliance Cost Correlation¶

🖥️ Runbooks CLI🤖 Prompts

# [A3-FinOps] Check compliance costs
runbooks finops check-config-compliance --all-profile $AWS_MANAGEMENT_PROFILE

/finops:report

Business Value: Unattributed spend prevents chargebacks to teams and blocks FinOps alignment. The CFO cannot answer "which team spent $40K this month?" when the majority of monthly spend is unattributed. Tag-enforced chargeback via SCP + naming standard prevents waste (teams control their spend when they see it) and unblocks the 5–8% EC2-Other and RDS optimization that was hiding behind attribution gaps. Every resource carries project/cost-center/environment tags by design; compliance is continuous, not reactive. Regulatory findings on cost attribution are prevented; business units achieve permanent showback clarity.

4. Governance — OU-Level SCP Inheritance¶

Owner: CDO · Also: CEO · Board asks: "Are our guardrails enforced or just advisory?"

The Challenge: Config shows partial compliance (not enforced). The majority of SCPs attach per-account (managing drift on every change), only a minority at OU level.

The Value: OU-level inheritance + conformance packs → continuous-assured compliance.

🖥️ Runbooks CLI🤖 Prompts

# [A2-Inventory] Assess current Config compliance and SCP effectiveness
runbooks cfat assess --all-profile $AWS_MANAGEMENT_PROFILE

# [A2-Inventory] Check SCP coverage and OU attachment strategy
runbooks inventory collect --all-profile $AWS_MANAGEMENT_PROFILE

/cfat:assess

Business Value: Per-account SCP attachment means every account-create or team-onboard must re-apply guardrails manually — toil and a drift vector. Compliance becomes an audit finding ("this account lacks the region-lock SCP") instead of a design fact. OU-level SCP inheritance + conformance packs move governance from reactive (audit → remediate every cycle) to continuous (policy → drift-detected automatically → remediate or alert). Drift on every change is eliminated by design. Config rule-compliance moves from critically low to fully compliant; regulatory findings on continuous controls are prevented. Governance becomes a cloud foundation property, not an operational chore.

5. Security — GuardDuty 100% Enrollment¶

Owner: CSO · Also: CTO · Board asks: "Is every account monitored for threats?"

The Challenge: Nearly all accounts have threat detection enabled. A minority of accounts lack a GuardDuty detector. SecurityHub delegated-admin is misconfigured.

The Value: Control Tower enrollment closes the coverage gap to 100% automatically. Proof the foundation is sound.

🖥️ Runbooks CLI🤖 Prompts

# [A2-Inventory] List all GuardDuty detectors and identify gaps
runbooks inventory list-guardduty-detectors --all-profile $AWS_MANAGEMENT_PROFILE

# [A2-Inventory] Assess security posture across all frameworks
runbooks security assess --all-profile $AWS_MANAGEMENT_PROFILE

# [HITL-gate] Deploy GuardDuty to gap accounts (WRITE — HITL approval required)
runbooks security deploy-guardduty --all-profile $AWS_MANAGEMENT_PROFILE

/aws:security-posture

Certificate & Identity Hygiene¶

🖥️ Runbooks CLI🤖 Prompts

# [A2-Inventory] Check certificate and identity status
runbooks security cert-inventory --all-profile $AWS_MANAGEMENT_PROFILE

/security:cert-inventory

Business Value: Coverage gaps mean blind spots on those accounts. A threat detected in most accounts but silent on a minority is a coverage hole the CSO cannot explain in an audit. 100% GuardDuty coverage + centralized SecurityHub delegated-admin means threat signals are comprehensive, actionable, and reported to a single pane. Control Tower enrollment closes the coverage gap to 100% automatically; new accounts inherit threat detection by default. At the next audit, the CSO confirms blanket GuardDuty coverage. Regulatory findings on monitoring completeness are prevented by design. The security foundation is proven managed and continuous, not ad-hoc.

6. Infrastructure — LZA Network Baselines¶

Owner: CTO · Also: VP-Infra · Board asks: "Can we onboard the next account in minutes?"

The Challenge: A large hand-rolled network estate exists with no drift detection or auto-inheritance for new accounts.

The Value: LZA network-config templates VPC/TGW as versioned drift-detected baselines.

🖥️ Runbooks CLI🤖 Prompts

# [A1-Discovery] Analyze network topology and resource relationships
runbooks vpc analyze --all-profile $AWS_OPERATIONS_PROFILE

# [A1-Discovery] Discover VPC and Transit Gateway configuration
runbooks vpc topology --all-profile $AWS_OPERATIONS_PROFILE

# [A1-Discovery] Check for CloudFormation drift in network stacks
runbooks inventory find-cfn-drift --all-profile $AWS_OPERATIONS_PROFILE

# [A2-Inventory] Validate overall Landing Zone configuration
runbooks inventory check-landingzone --all-profile $AWS_MANAGEMENT_PROFILE

/aws:vpc-investigate

Landing-Zone Configuration Validation¶

🖥️ Runbooks CLI🤖 Prompts

# [A2-Inventory] Validate Landing Zone readiness for account vending
runbooks inventory check-landingzone --all-profile $AWS_MANAGEMENT_PROFILE

/inventory:lz-cross-validate

Business Value: A large hand-rolled network estate is a configuration debt — many different ways to misconfigure subnets, routing, NAT, and security groups. New account onboards require manual VPC design (toil, error-prone). Drift is invisible until a misconfigured subnet causes an incident. LZA or Terraform modules convert VPC/TGW into versioned infrastructure. New account = template instantiation (seconds, no mistakes). Drift detection runs continuously; misconfigured subnets are detected in minutes, not quarters. Network design is consistent by default; the longest engagement of the six, but VP-Infra gains permanent automation: account velocity increases, operational risk decreases, and the hand-rolled estate is eventually retired.

Next Steps¶

Identify the functional area your role owns (BC=CSO/CEO, Ops=CTO, Finance=CFO, Governance=CDO, Security=CSO/CTO, Infrastructure=VP-Infra).
Choose your execution path: - Runbooks CLI → direct commands to assess and remediate today (ops teams). - Prompts → paste the /command into your terminal to coordinate autonomous execution via agents (distributed teams, HITL review gates).
Engage your cloud architect to review the gap-close approach, estimate timeline, and manage dependencies with other areas.

For detailed command options, see Runbooks CLI Catalog.