Customer OCI governance · 01

STEP 1 — Customer OCI Governance (Before Anything Is Built)

Governance is written, ratified, and signed before the first console click that mutates the tenancy. The output of Step 1 is a governance pack of five artifacts, each version-controlled in the customer's repository and approved via merge request (the MR is the signature).

1.1 Establish the Governance Operating Model

Stand up the governing bodies and decision rights first — every later dispute (a vendor wants a policy widened, an app team wants a public endpoint) is resolved by this structure rather than by escalating emails:

Body / Role	Composition	Cadence	Decision rights
Cloud Governance Board	Executive sponsor, security lead, platform lead, app owners, partner delivery lead	Monthly + ad-hoc for exceptions	Ratifies standards, approves exceptions/ADRs, owns risk acceptance
Security & Compliance	{Customer} security team	Continuous	Owns security baseline, Cloud Guard stance, audit/SIEM, access certification
Platform Access (IAM)	Identity team	Continuous	Owns identity domains, group registry, federation, break-glass custody
Infrastructure Operations	Platform/CloudOps engineers	Continuous	Owns compartments, network, IaC, Day-2 operations
Business Application Owners	Per Fusion pillar (ERP/HCM/SCM/CX/EPM)	Per release	Own SaaS-plane decisions; consume, never administer, the OCI control plane

Adapt names to the customer's organization; keep the separation of duties: the team that approves policies is never the only team that writes them.

1.2 Author the Governance Pack (five artifacts)

Governance Framework — purpose, principles, bodies above, environment strategy (how many Fusion pods and OCI environments, and their promotion path), and the co-tenanted/isolated decision with rationale.

OCI Governance Standard — the normative control document using MUST/SHOULD language: identity domain topology, group registry, administrative and break-glass accounts, compartment structure rules with an ownership registry, IAM policy authoring rules and a baseline catalog (nothing at root except security-read and break-glass), tagging standard, network governance, security services stance, cost governance, data classification.

Security Governance & Responsibility Matrix — RACI per governance domain (identity, network, security posture, cost, data, integrations) across customer teams, the implementation partner, and Oracle. Explicitly mark the Oracle-operated SaaS responsibilities (pod patching, pod DR) as out of customer scope.

Naming & Tagging Standards — naming pattern {org}-{region-code}-{env}-{service}-{seq} with a published regex; one defined-tag namespace (e.g., Governance or CloudOps) with mandatory keys: CostCenter, Environment, Owner, Workload, DataClass, ManagedBy. Plan enforcement in three layers: tag defaults per compartment, IaC review, and periodic audit.

Platform Service Annexes — one annex per procured PaaS service (OIC, ATP, FDI/Analytics, Object Storage, SFTP/agent VMs): who may provision, where it is placed, network exposure rules (private endpoints by default), and operational standards.

1.3 Compartment Model (generic reference)

Compartment	Purpose	Notes
{tenancy} root	Nothing deployed here	Only security-read + break-glass policies at root
Governance	Audit sinks, Logging, Log Analytics, Cloud Guard target, budgets, Vault (master keys)	Security team owned
Shared-Services	Hub VCN, DRG, FastConnect/VPN, DNS, bastion, monitoring	Network team owned; children per function
Applications → {env} → {PaaS \| Compute \| Data \| Network}	OIC instances, ATP, Object Storage, agent/SFTP VMs, spoke VCN resources per environment (Dev/Test/Prod)	One env sub-tree per environment; spoke VCN per env
SaaS	SaaS handle sub-compartments per Fusion pillar (no infrastructure)	Anchors Fusion-adjacent policies; keeps SaaS references out of app compartments
Analytics	FDI/OAC + managed ADW	Prod first, then non-prod
Sandbox	Time-boxed experiments	Quota-capped; auto-review for teardown

1.4 Identity Governance Decisions (record now, implement in Step 3)

Identity domain topology: default identity domain reserved for tenancy administration; a workforce domain federated to the customer IdP (Entra ID / Okta / other) supplying both OCI console users and Fusion users; decide whether Fusion pods authenticate through the same workforce domain (co-tenanted default) or a dedicated domain.

Group registry: canonical group list (network-ops, app-devs, app-admins, db-admins, security, cost-audit, analytics, per-vendor groups, breakglass-admins, readonly-global) mapped to IdP groups — groups are born in the IdP, mirrored to OCI, never hand-created ad hoc.

Administrative accounts: named admins only, MFA mandatory, no shared accounts, no API keys on tenancy admins; break-glass procedure with sealed credentials and post-use rotation.

Vendor/partner access: per-vendor groups scoped to specific compartments with time-boxed access certification.

1.5 Exit Criteria — Step 1

Governance pack (five artifacts) merged and ratified by the Governance Board; co-tenanted vs isolated decision recorded with rationale; compartment model, group registry, naming/tagging standards signed; responsibility matrix acknowledged by customer, partner, and functional teams.

STEP 1 · DOCUMENT 1 OF 6

Customer OCI Governance Standard

Governance framework for OCI tenancy + Oracle Fusion Cloud — co-tenanted or isolated · IaaS+PaaS (OIC · ATP · Object Storage · SFTP VM) and/or SaaS (ERP · HCM · SCM · CX · EPM)

Pre-engagement artifact. Approved by the customer Cloud Governance Board before any Day 0 activity. All subsequent runbooks (Docs 2–6) execute under this standard.

OCI Governance Sample

Field	Value
Document ID	<CUSTOMER>-GOV-OCI-001
Version	v1.0 (Generic Template)
Execution model	OPTION A — FULLY MANUAL (human engineers, OCI Console; no IaC/automation in the build path)
Customer	<CUSTOMER> — replace on engagement start
Tenancy	<TENANCY-NAME> / OCID: <TENANCY-OCID>
Prepared by	Cloud Platform Engineering
Review cycle	Per engagement; template annually

How to use this generic template

Placeholders: replace <CUSTOMER>, <TENANCY-NAME>, <HOME-REGION>, <SECONDARY-REGION>, <IDP> (Entra ID / Okta), <CIDR-*> and e-mail distribution lists at engagement start. Search the document for "<" to find all placeholders.

Tenancy model branch: sections marked [CO-TENANTED] apply when Fusion SaaS and OCI IaaS/PaaS share one tenancy; sections marked [ISOLATED] apply when SaaS and IaaS/PaaS run in separate tenancies. Execute only the branch selected in the Discovery Questionnaire.

Service scope branch: sections marked [IAAS+PAAS] apply only when the customer procures OCI platform services (OIC, ATP, Object Storage, SFTP VM, network). Sections marked [SAAS] apply to Fusion ERP / HCM / SCM / CX / EPM touchpoints visible from OCI. SaaS-only customers skip [IAAS+PAAS] sections.

Questionnaire inputs: each runbook opens with an input table mapping Cloud Discovery Questionnaire item IDs (DS.*, DC.*, CT.*, TF.*, AC.*, NR.*, IAM.*, SEC.*, OM.*, DR.*, OIC.*) to the fields the procedures consume. Do not start execution until every listed input is answered by the customer.

Manual-only rule: every resource in this series is created by a human engineer in the OCI Console. Read-only tooling (CD3 export, CIS compliance checker script) is permitted for evidence and documentation only — it must never create, modify, or delete resources.

1. Purpose and Scope

This governance standard establishes the accountability model, security principles, structural standards, and operational controls for the customer’s Oracle Cloud estate. It is the first artifact of every engagement: it is reviewed with the customer, adapted to their organization and compliance frame, and approved by their governance body before the tenancy is touched. Every action in the Day 0, Day 1, and Day 2 runbooks traces back to a control in this document.

1.1 Services in scope

Plane	Services	Governed by
SaaS (functional plane)	Oracle Fusion Applications — ERP, HCM, SCM, CX, EPM (per licensed pillars). Oracle-managed pods reached over the Oracle Services Network.	Fusion application security (in-pod). This document governs only the OCI-visible touchpoints: SSO/federation, environment mapping, SaaS handle compartments, OSN connectivity.
IaaS + PaaS (platform plane)	OCI Integration (OIC + File Server), Autonomous Database (ATP), Object Storage, SFTP/utility VMs, VCN networking, Vault/KMS, Logging, Cloud Guard, budgets/quotas.	This document, in full.
Identity	Customer IdP (<IDP>: Microsoft Entra ID or Okta), OCI IAM identity domains, federation, groups, policies.	This document + customer identity standard.

TWO-PLANE BOUNDARY:OCI IAM controls who can administer cloud resources. Fusion RBAC controls who can act inside the applications. They are separate control planes with separate administrators, separate review cycles, and separate audit trails. Never conflate them: an OCI administrator has no implicit Fusion access, and a Fusion administrator has no implicit OCI access.

1.2 Tenancy model decision

DECISION POINT:Select ONE tenancy model at contract time, before Day 0. Record the decision, its rationale, and the approver in the engagement decision log. Changing models after landing-zone build is a re-architecture, not a change request.

Model	Description	Choose when	Governance consequences
[CO-TENANTED]	One tenancy carries the Fusion SaaS subscriptions and all OCI IaaS/PaaS infrastructure.	Default for single-org customers; simplest SSO, one bill, one governance surface; Fusion pods and OCI platform administered by the same customer IT organization.	SaaS handle compartments live beside platform compartments; one identity domain strategy serves both; budgets must separate SaaS subscription cost from consumption cost.
[ISOLATED]	Fusion SaaS subscriptions live in one tenancy; IaaS/PaaS platform lives in a second tenancy (or the SaaS tenancy is Oracle/SI-controlled).	Separate purchasing vehicles; different administrative owners; regulatory isolation demands; multi-org or M&A structures; SI-operated platform.	Two Day 0 runbook executions (one per tenancy); cross-tenancy IAM policy or network path required for any platform-to-SaaS integration; two budget/announcement/Cloud Guard scopes; federation configured per tenancy.

2. Governance Principles

Principle	Meaning in practice
Security by Design	Security controls are incorporated into every OCI and Fusion-adjacent solution from inception, not retrofitted.
Risk-Based Governance	Cloud cybersecurity risk is managed under the customer’s framework of record (default: NIST CSF 2.0; substitute ISO 27001, CIS Controls, or industry frame per the Discovery Questionnaire item 0C.02). Activities map to Govern / Identify / Protect / Detect / Respond / Recover.
Least Privilege	Access is granted only to the extent necessary; absence of a policy grant IS the deny.
Segregation of Duties	No single individual may request, approve, deploy, and validate the same security-sensitive activity.
Manageability by Design	A consistent hierarchical compartment design and standard Oracle security functionality keep governance simple enough to operate manually.
Standardization	All resources follow the approved naming, tagging, deployment, and monitoring standards in this document.
Ownership	Every resource, integration, report, and dataset has a named business owner and technical owner (enforced via mandatory tags).
Documentation of Manual Work	Because this engagement executes Option A (fully manual), every console action that creates or changes a resource is recorded in the build log (Doc 6 §2) the same day. The as-built extract (CD3) is reconciled against design at every phase gate.

3. Governance Structure and RACI

Rename the role columns to the customer’s actual team names during adaptation; keep the separation between the six functions even if one team wears several hats in a small organization — the separation is what the SoD controls in §11 attach to.

Function	Core responsibilities	Accountable for
Cloud Governance Board	Reviews strategy, architecture direction, major decisions, risk posture, exceptions; approves this standard, the HLD/LLD, and phase-gate exits.	Governance oversight; strategic risk acceptance.
Executive Leadership	Risk acceptance, funding, policy approval, compliance sponsorship.	Compliance posture; residual risk; enterprise cloud strategy.
Security & Compliance	Security governance, risk register, maturity assessments, vulnerability management, incident response, audit coordination, exception governance.	Security program effectiveness; regulatory compliance; audit readiness.
Platform Access Team (IAM)	OCI IAM administration, identity federation, MFA/CA, user lifecycle, group administration, access reviews, service-account governance. Where the customer assigns it: Fusion security administration.	Authentication and authorization controls; identity governance.
Infrastructure Operations	OCI administration, networking, compute, storage, DNS, backup/recovery, monitoring, DR operations.	Platform stability, performance, availability, resilience.
Application Development	Development lifecycle governance for extensions/integrations, source control, release practices, deployment readiness.	Secure development practices; release readiness.
Data & Analytics	Analytics platform ownership (FDI/OAC), data pipelines, semantic models, lineage, data quality, governed data flows.	Analytics architecture; data flow and quality oversight.
Business Application Owners	Application administration, business process ownership, data stewardship, UAT approval, change approvals.	Data quality; process effectiveness; application functionality.

NOTE:Small-team adaptation: a 2–5 person customer IT team may map Security & Compliance + IAM to one person and Infrastructure Operations + Application Development to another. Record the mapping in the adapted standard. The SoD minimum that survives any collapse: the person who implements a production change is never the sole approver of it, and the person who grants privileged access does not approve their own request.

4. Tenancy and Compartment Structure

The tenancy is organized into top-level compartments separating shared platform services, production, non-production, development, DR, and regulated workloads. Compartment boundaries align to ownership, environment, data sensitivity, and cost accountability. Production is always isolated from non-production.

Top-level compartment	Purpose	Present when
Governance	Audit sinks, logging, Cloud Guard target, budgets, tag namespace.	Always.
Shared-Services	Networking (all VCNs), identity integration objects, shared tooling, Vault/KMS.	Always ([IAAS+PAAS]).
Applications:<ENV>	Per-environment workload compartments (children: PaaS instances, internal apps, vendor workspaces).	[IAAS+PAAS].
SaaS	Subscription handle compartments per Fusion pillar (ERP / HCM / SCM / CX / EPM) — hold no infrastructure.	[CO-TENANTED] with SaaS; in [ISOLATED], these live in the SaaS tenancy.
Analytics	FDI / OAC and custom analytics schemas.	When analytics licensed.
Regulated-Workloads	Contract-sensitive or regulated systems needing enhanced controls (e.g., CMMC/FCI scope, PCI segment).	When Questionnaire 0C.02/0C.03 answers demand it.
Sandbox	Innovation and PoC; quota-capped.	Optional.
DR	Reserved, empty until the DR strategy decision lands.	When a secondary region is in scope (Questionnaire DR.*).

4.1 Environment model

Code	Environment	Notes
DEV / DEV1 / DEV2	Development and configuration	Parallel DEV streams only when two build teams work concurrently.
TST	System integration and regression testing	Production-equivalent security rules from TST upward.
UAT	Business validation and acceptance	For Fusion, usually a phase of the Test pod, not separate infrastructure — a cost decision the Board takes explicitly.
PRD	Production	Security Zone enforced; no Internet Gateway; restricted access.
SBX	Sandbox / PoC	Quota-capped; no production data, ever.
TRN	Training	Optional; often a Fusion pod phase.
DR	Disaster recovery	Activated by the DR decision; paired with <SECONDARY-REGION>.

5. Identity and Access Governance

Layer	Control	Purpose
Identity Provider	<IDP> (Entra ID / Okta)	Single source for user identity, authentication, MFA, and group membership.
Federation	OCI identity domain federation (SAML 2.0; SCIM or JIT provisioning)	Approved IdP identities and groups reach OCI without local users.
Authorization	OCI IAM groups (OCI-* standard, §6)	Map users to approved administrative, development, support, and audit roles.
Enforcement	OCI IAM policies	Define permitted actions, target compartments, service-level boundaries.

MFA is required for all interactive access.

Federated identities are used wherever supported; local OCI accounts are prohibited except the two approved break-glass accounts (Doc 3 §A1).

Privileged access requires documented approval and periodic review; all access reviewed quarterly.

Service accounts have named owners, documented purpose, credential rotation ≤ 90 days, and monitoring.

Fusion SSO federates each pod to the same IdP; account provisioning into Fusion is driven from HCM where licensed.

6. OCI Group Standard

Groups establish RBAC across the tenancy. Membership is assigned through federated IdP groups. The standard set below covers both scope branches; create only the groups the engagement needs, but never invent names outside the pattern.

Group	Purpose	Branch
OCI-TENANCY-ADMIN	Bootstrap/emergency full administration; membership ≈ 0 in steady state; executive approval to join.	Always
OCI-IAM-ADMIN	Identity domains, federation, groups, policies. Cannot self-approve privileged access.	Always
OCI-NETWORK-ADMIN	VCNs, gateways, routing, LBs, network security.	[IAAS+PAAS]
OCI-SECURITY-ADMIN	Cloud Guard, Security Zones, Vault, logging, audit, tag namespace. Cannot provision users or infrastructure.	Always
OCI-AUDITOR	Read-only tenancy-wide + usage reports; zero write.	Always
OCI-COST-AUDIT	Read tenancy + usage reports for cost governance.	Always
OCI-FUSION-ADMIN	Reads SaaS handle compartments; Fusion administration happens in-pod under the Fusion security standard.	[SAAS]
OCI-OIC-ADMIN / OCI-OIC-DEVELOPER	OIC platform administration / integration development (DEV only; TST-PRD changes via controlled promotion).	[IAAS+PAAS]
OCI-DB-ADMIN	database-family in PRD; read TST.	[IAAS+PAAS]
OCI-APP-ADMIN	Manage Applications:TST/PRD (controlled promotion); read tenancy.	[IAAS+PAAS]
OCI-DEVELOPER	Manage Applications:DEV* and Sandbox; use DEV subnets only.	[IAAS+PAAS]
OCI-SUPPORT	Read applications + analytics; monitor roles; no manage.	Always
OCI-FDI-ADMIN / OCI-REPORT-DEVELOPER	Analytics compartment administration / report authoring.	Analytics
OCI-VENDOR-<NAME>	Per-vendor workspace access, time-boxed guest identities; one group per vendor, never shared.	When SI/vendors build
OCI-REGULATED-OPS	Manage Regulated-Workloads; restricted membership, Security approval.	Regulated scope
OCI-BREAKGLASS-ADMIN	Emergency manage-all; local Default-domain users only; login alarm mandatory.	Always

7. IAM Policy Governance

Least privilege; role-based; compartment-scoped. Nothing at root except security-read, auditor-read, cost-read, and break-glass.

One policy resource per compartment per purpose, named pol-<compartment>-<purpose>, so policies are findable and reviewable.

Absence of a grant IS the deny. Deny-style thinking ("who must NOT see this") is expressed by scoping grants narrowly, not by broad grants with exceptions.

Quarterly policy review by IAM + Security; every policy change follows the change workflow (§12).

Example: Allow group OCI-OIC-ADMIN to manage integration-instance-family in compartment Applications:PRD:PaaS

8. Naming Standard

Resource format: <ENV>-<APP>-<SERVICE>-<PURPOSE>-<SEQ>

Category	Approved codes	Notes
Environment	PRD, UAT, TST, DEV, DEV1, DEV2, SBX, TRN, DR	Lifecycle stage.
Application	ERP, HCM, SCM, CX, EPM, FIN, OIC, VBS, FDI, PLATFORM	Business application or platform domain.
Service / resource	VCN, SUBNET, NSG, SGW, NAT, DRG, RT, OIC, ADB, VM, BUCKET, VAULT, KEY, SEC, LB, REPORT, JOB	Short recognizable codes.
Sequence	01, 02, 03 …	Two digits.

Examples: PRD-ERP-OIC-PAYMENT-01 · PRD-PLATFORM-VCN-CORE-01 · DEV-SCM-ADB-SUPPLIER-01 · PRD-PLATFORM-VM-SFTP-01

OIC integrations: <DOMAIN>-<SOURCE>-<TARGET>-<FUNCTION> e.g., FIN-ERP-BANK-PAYMENT, HCM-FUSION-AD-WORKER

Compartments: PascalCase, hierarchy carries meaning (Governance · Shared-Services · Applications:DEV1:PaaS). Groups: OCI-* (§6). Policies: pol-<compartment>-<purpose>.

9. Tagging Standard

One protected tag namespace (named for the customer, e.g., <CUSTOMER>) administered by OCI-SECURITY-ADMIN only. Required keys are enforced with per-compartment tag defaults so untagged resources cannot be created.

Key	Type / values	Required
BusinessUnit	LOV: finance-approved BU list	Yes
CostCenter	LOV: finance-approved	Yes
ApplicationOwner	Named person/role	Yes
TechnicalOwner	Named team	Yes
Environment	LOV: PRD·UAT·TST·DEV·SBX·TRN·DR (defaulted per compartment)	Yes (default)
Service	LOV: ERP·HCM·SCM·CX·EPM·OIC·VBS·FDI·PLATFORM	Yes
Criticality	LOV: Critical·High·Medium·Low	Yes
DataClassification	LOV: Public·Internal·Confidential·Restricted	Yes
BackupTier	LOV: T1-Daily·T2-Weekly·T3-None	Yes (defaulted)
SupportGroup	LOV: InfraOps·AppDev·DataAnalytics·IAM·Security·Vendor-*	Yes (defaulted)
RegulatoryScope	LOV: None·<frameworks from 0C.02> (≠ None only in Regulated-Workloads)	Yes (default None)
DRTier	LOV: DR1-Replicated·DR2-Backup·DR3-Rebuild	Should (until DR decision)
ChangeWindow	LOV: Standard·Weekend·Frozen	Should
Partner	LOV: Internal·<vendor names>	Yes in Applications when vendors build

10. Platform Service Governance [IAAS+PAAS]

10.1 OIC

One OIC project per business domain per direction; no integration lives outside a project. Naming per §8.

Lifecycle DEV → TST → UAT → PRD with documented testing, peer review, and deployment approval at each promotion. In fully-manual mode, promotion = export IAR from source instance / import to target with a config plan, executed by a second engineer, recorded in the build log.

Connection credentials come only from Vault-held secrets; service accounts per target system per environment (svc-oic-<env>-<system>); no personal accounts in connections.

Every integration attaches the global fault handler; faults land in the error queue with retry metadata; no silent catch-and-continue.

File Server folders: OIC/<project>/{in,out,archive,error}; group-based grants; SFTP keys per counterparty stored in Vault; archive to Object Storage after 90 days.

10.2 ATP

ATP holds staging, cross-reference, and custom application data only — never a copy of the Fusion transactional store.

Private endpoint only; mTLS wallet; no public ACL paths. NSG-scoped 1522 ingress.

DB credentials in Vault; rotation ≤ 90 days; monitoring read-only user separate from application users.

Automatic backups (60d) + long-term monthly for PRD; cross-region backup copy when <SECONDARY-REGION> subscribed.

10.3 Object Storage and SFTP VM

Buckets versioned; lifecycle rules mandatory (archive/delete per data class); no public buckets — Cloud Guard treats a public bucket as a critical finding.

SFTP VM (when OIC File Server is not used): hardened image, private subnet, key-only auth, per-counterparty chroot directories, session logging shipped to the Logging service, fail2ban or equivalent.

10.4 Fusion touchpoints [SAAS]

Pod-to-environment mapping is recorded in the environment matrix (Doc 6 as-built) and kept current after every P2T/T2P refresh.

SSO federation per pod to <IDP>; provisioning from HCM where licensed.

After every Fusion refresh: re-point OIC connections (config plans), refresh ATP cross-reference data, re-baseline FDI non-prod. This is a standing Doc 4 procedure.

Fusion quarterly update regression testing is a Business Application Owner obligation; OCI-side smoke tests accompany it.

11. Segregation of Duties

Function	May not
IAM	Approve its own privileged access requests.
Security & Compliance	Provision or administer infrastructure/users (keeps audit independence).
Infrastructure Operations	Modify audit records; self-elevate privileges.
Application Development	Approve its own production releases.
Data & Analytics	Bypass access approval for data sources.
Business Application Owners	Touch OCI IAM or security policy.

MANUAL-MODE COROLLARY:In Option A every change is hand-executed, so SoD is enforced by people and evidence, not pipelines: each production console change requires a second engineer as reviewer (four-eyes), and the build log records executor + reviewer per action. This substitutes for the PR-review gate an IaC pipeline would provide.

12. Change Management

Step	Activity	Purpose
1	Request	Scope, business need, risk, affected services, window.
2	Technical review	Architecture, dependencies, approach, rollback plan.
3	Security review	Security impact, access, compliance, logging.
4	Testing validation	Evidence, expected outcomes, regression impact.
5	Business approval	Acceptance, scheduling, user impact.
6	CAB approval	Authorization after reviews complete.
7	Deployment	Manual execution per runbook, in window, four-eyes.
8	Post-implementation review	Validate, document, lessons learned, close.

Applies to: OCI infrastructure, Fusion configurations and security roles (via the Fusion change process), OIC integrations, IAM (federation, groups, policies, service accounts), and security controls. Landing-zone build activities (Docs 2–4) execute under a single pre-approved change umbrella per phase, with the phase-gate review standing in for steps 2–6 of each individual action.

13. Cybersecurity Framework Ownership

CSF Function	Primary owner	Principal OCI mechanisms
Govern (GV)	Executive Leadership / Security & Compliance	This standard; Governance Board; exception register; KPIs.
Identify (ID)	Security & Compliance	Tag-driven inventory; compartment registry; risk register.
Protect (PR)	IAM / Infrastructure / App Dev / Data / App Owners	IdP CA+MFA; OCI-* groups + least-privilege policies; Security Zones; NSGs; Vault/KMS; SoD.
Detect (DE)	Security & Compliance / Infrastructure Ops	Cloud Guard; audit/service/flow logs; alarm routing.
Respond (RS)	Security & Compliance + supporting teams	Cloud Guard problem workflow; break-glass alarms; integration error queue.
Recover (RC)	Infrastructure Ops / Data / App Owners / Exec	Backups + cross-region copies; documented rebuild runbooks (this series IS the rebuild path in manual mode); DR compartment.

NOTE:Substitute the customer’s framework of record if it is not NIST CSF (Questionnaire 0C.02). Keep the ownership column intact — the mapping of function to owner survives any framework swap.

14. Governance Metrics

Domain	Metrics
Security	MFA compliance % · vulnerabilities past SLA · access review completion · high-risk findings open > 90d · Cloud Guard critical findings open.
Operations	Availability % · MTTR · backup success rate · DR exercise success rate.
Governance	Tag compliance % · policy violations · cost variance vs budget · exception volume · CIS benchmark score trend (Doc 5).
Delivery (manual mode)	Build-log completeness (actions with executor+reviewer / total actions) · as-built drift count per CD3 reconciliation (Doc 6) · phase-gate first-pass rate.

15. Engagement Adaptation Checklist

Complete before presenting this standard to the customer governance body:

Replace all placeholders (<CUSTOMER>, <TENANCY-NAME>, <IDP>, regions, e-mail lists).

Confirm licensed Fusion pillars against the Oracle subscription document (never against verbal scope) and strike unlicensed pillars from §1.1, §6, §9.

Select the tenancy model (§1.2) and delete the branch not taken.

Select the service-scope branch; SaaS-only customers delete §10.1–10.3 and all [IAAS+PAAS] rows.

Map §3 functions to the customer’s real teams; record collapses and the surviving SoD minimum.

Swap the compliance frame in §2/§13 per Questionnaire 0C.02; add regulated-workload handling if 0C.03 lists protected data classes.

Present to the Cloud Governance Board; record approval (name, date) on the cover; only then start Doc 2 (Day 0).

Revision History

Version	Date	Description
1.0	<DATE>	Generic template — adapted from field-proven customer governance frameworks (construction/engineering and energy-services engagements).