Responsibility Matrix Templates

This appendix is a working reference for turning the shared responsibility model into an operating artifact. Responsibility matrices are useful only when they map real services and controls to real owners, evidence, and review points. Use these templates as starting structures for architecture reviews, service onboarding, control programs, and audit preparation.

The templates are intentionally plain and reusable. Adapt them to your own naming conventions, but keep the core fields stable enough that teams can compare services and controls across the organization.

    flowchart LR
	    A["Service or workload"] --> B["Responsibility matrix"]
	    B --> C["Named owners"]
	    B --> D["Evidence and review cadence"]
	    C --> E["Operational accountability"]
	    D --> E

How to Use These Templates

Use the smallest template that answers the actual question in front of you:

• use a service boundary matrix when a team is onboarding or reviewing one platform or workload
• use a control matrix when you need to show who owns a specific control and how it is evidenced
• use a cross-team handoff matrix when the main risk is ambiguity between internal teams
• use an evidence tracker when a control exists but audit and review evidence is inconsistent

Do not turn every template into one giant spreadsheet. A matrix is strongest when it remains close to the decision it supports.

Template 1: Service Boundary Matrix

Use this when you need a quick service-level picture of the provider boundary and the customer boundary.

 1service_boundary_matrix:
 2  service: example-managed-database
 3  workload: customer-billing
 4  service_model: managed-platform-service
 5  provider_owned:
 6    - underlying_infrastructure_operations
 7    - service_patch_management
 8    - platform_availability_within_scope
 9  customer_owned:
10    - access_control_configuration
11    - backup_policy_selection
12    - log_review_and_alerting
13    - workload_data_classification
14  shared_controls:
15    - encryption_configuration_and_key_governance
16    - audit_logging_enablement_and_retention
17  accountable_customer_owner: cloud-platform
18  review_cadence: quarterly

What to notice:

• this template is for boundary clarity, not full audit detail
• provider-owned, customer-owned, and shared areas should all be explicit
• one accountable customer owner should still be named even when several teams contribute

Template 2: Control Ownership Matrix

Use this for audit and governance work when you need one row per control.

What to notice:

• Ownership Type should be one of Inherited, Shared, or Customer
• Provider Contribution should stay concrete instead of saying only “cloud provider”
• Evidence Source should name something retrievable, not a vague category like “logs”

Template 3: Cross-Team Handoff Matrix

Use this when the main risk is not provider ambiguity but internal team ambiguity.

 1cross_team_handoff:
 2  control: sensitive_data_access_monitoring
 3  accountable_owner: security-operations
 4  contributors:
 5    application-team:
 6      responsibility: emit_business_context_events
 7    data-governance:
 8      responsibility: define_sensitive_data_scope
 9    cloud-platform:
10      responsibility: route_logs_to_central_pipeline
11  escalation_owner: security-operations
12  failure_signal:
13    - alert_fires_without_business_context
14    - logs_present_but_not_retained

What to notice:

• contributor detail matters because “shared” without task definition usually hides a gap
• escalation ownership should be explicit
• failure signals help teams detect when the matrix is no longer matching reality

Template 4: Service Onboarding Checklist Matrix

Use this during architecture review or pre-production onboarding.

What to notice:

• this template is meant to force key ownership questions before launch
• follow-up fields matter because the goal is remediation, not only review
• keep the number of rows small enough that teams actually use it

Template 5: Incident Coordination Matrix

Use this when a control path spans customer teams and provider support.

 1incident_coordination_matrix:
 2  scenario: suspicious_admin_activity
 3  provider_role:
 4    - supply_platform_side_context
 5    - confirm_managed_service_health
 6  customer_roles:
 7    incident_commander:
 8      owner: security-operations
 9    tenant_containment:
10      owner: identity-security
11    workload_scoping:
12      owner: application-team
13    executive_and_regulatory_updates:
14      owner: governance-risk-compliance
15  required_evidence:
16    - timestamps_utc
17    - resource_ids
18    - audit_log_extracts

What to notice:

• provider participation should be described as support for the provider-owned layer, not as ownership of the customer incident
• the customer side should still include explicit containment, scoping, and communication owners
• evidence requirements belong in the same template because incident coordination fails when evidence is vague

Template 6: Evidence and Review Tracker

Use this when control ownership is known but evidence collection is inconsistent.

What to notice:

• a matrix becomes more useful when it exposes drift plainly
• Gap should be written in operational language, not audit language alone
• review dates help keep the matrix alive between audits

Template 7: Exception Register

Use this when the organization permits deviations from guardrails or standard control patterns.

 1exception_register:
 2  exception_id: EX-014
 3  workload: legacy-reporting-service
 4  deviates_from: central_identity_standard
 5  reason: vendor_limitations
 6  accountable_owner: service-owner
 7  compensating_controls:
 8    - quarterly_manual_access_review
 9    - ip_restriction_on_admin_interface
10  approval_owner: governance-board
11  review_date: 2026-09-30

What to notice:

• an exception without a review date is usually a permanent gap disguised as a temporary choice
• compensating controls should be explicit and testable
• approval ownership matters because exceptions are governance decisions, not informal team preferences

Suggested Review Routine

If you are starting from scratch, a simple routine is enough:

1. build service boundary matrices for tier-1 workloads first
2. add control ownership rows for the highest-risk controls
3. create evidence trackers only for the controls that need recurring proof
4. review exceptions and overdue evidence on a fixed cadence

The point is not to build perfect documentation. It is to make ownership visible, current, and usable before ambiguity turns into an incident or audit finding.