A developer needs an object-storage bucket.
The request sounds ordinary:
Create a private bucket for product images.
The organisation responds with a form.
The form asks:
- which business unit approves the data
- whether the architecture board has reviewed the design
- which security contact has accepted the risk
- whether finance has assigned a cost centre
- which network team will permit access
- which operations team will monitor it
The developer submits the request.
Several days later, a meeting is arranged to clarify why the bucket is required.
Another team asks whether a database would be more appropriate.
The security review discovers that public access should be disabled.
Finance asks whether lifecycle rules are enabled.
The platform team eventually creates the bucket manually.
The result is secure.
The process is not scalable.
The organisation has attempted to govern one routine resource by assembling a temporary parliament around it.
At the other extreme, a developer may have unrestricted cloud access and create:
public bucket
unencrypted storage
permanent access key
no retention policy
no cost ownership
no audit trail
That process is fast.
It is not controlled.
The useful design sits between these two failures.
Cloud governance should make safe decisions repeatable, visible and enforceable without forcing every ordinary action through a human checkpoint.
Governance is not the act of making engineers ask permission.
It is the system through which an organisation decides:
- which outcomes must be protected
- who may make which decisions
- which conditions must remain true
- how those conditions are enforced
- what evidence demonstrates that the controls work
- how exceptions and emergencies are handled
- who remains accountable
A strong governance system allows ordinary, well-understood work to move quickly.
It reserves human attention for decisions that are genuinely exceptional, ambiguous or high risk.
The goal is not fewer controls.
It is better-shaped controls.
Governance decides outcomes and accountability
Governance is often presented as a collection of policies.
All production data must be encrypted.
Public access must be approved.
Resources must have owners.
Changes must be auditable.
These statements describe desired conditions.
They do not yet explain how those conditions become true.
A useful governance model separates four responsibilities.
GOVERNANCE
decides outcomes, decision rights
and accountability
POLICY
translates those decisions
into expected conditions
CONTROL
prevents, detects or corrects
conditions in the system
ASSURANCE
tests whether the controls
produce the intended outcome
For example:
GOVERNANCE DECISION
Customer records must remain private,
recoverable and regionally compliant.
POLICY
Confidential production data must use
approved encrypted storage
in permitted regions.
CONTROL
Platform profile, provider policy,
identity restrictions and monitoring.
ASSURANCE
Action tests, restore drills,
policy evidence and incident outcomes.
Governance decides what must be true and who is accountable.
Platforms and control systems make those decisions operable.
Without that distinction, governance can become another name for every rule, form, tool and meeting in the organisation.
Turn organisational decisions into operable controls
Some decisions genuinely require human judgement.
Examples include:
- accepting a significant data-protection risk
- introducing a new public exposure pattern
- adopting a high-cost architecture
- using an unapproved region
- bypassing a production guardrail
- changing an organisation-wide policy
Other decisions are predictable.
A production object store should usually be:
private
encrypted
owned
logged
tagged
covered by an approved retention policy
There is little value in asking a committee to rediscover those requirements for every bucket.
REPEATED DECISION
│
▼
STANDARD POLICY
│
▼
AUTOMATED CONTROL
Bureaucracy begins when the organisation treats routine and exceptional decisions as though they require the same process.
Good governance automates settled decisions and concentrates human judgement on uncertainty.
Policy should express outcomes before mechanisms
A policy can be written too closely to one implementation.
All workloads must use
security group sg-123456.
That may enforce one current mechanism.
It does not explain the outcome.
A stronger policy says:
Production workloads may accept inbound traffic
only from approved service entry points.
The implementation may use:
- security groups
- network policy
- service identity
- private load balancers
- firewall rules
Outcome-based policy survives architectural change more easily.
Mechanism-specific controls still matter.
They should remain traceable to the outcome they protect.
This prevents governance from becoming a museum of old infrastructure assumptions.
Controls should operate close to the action
A policy document in a wiki explains intent.
It does not stop an unsafe resource from being created.
POLICY DOCUMENT
says:
public storage prohibited
CLOUD API
still allows:
public storage
Possible enforcement points include:
- platform API validation
- pull-request checks
- infrastructure planning
- cloud organisation policy
- admission control
- runtime reconciliation
DEVELOPER INTENT
│
▼
EARLY VALIDATION
│
▼
INFRASTRUCTURE PLAN
│
▼
PROVIDER GUARDRAIL
│
▼
RUNTIME ASSURANCE
The earlier an unsafe request is rejected, the cheaper it is to correct.
Governance should travel towards the point of change rather than remain in a distant policy archive.
Prevent, detect and correct
Controls have different jobs.
PREVENT
stop the unsafe state
DETECT
identify the unsafe state
CORRECT
return the system
to an acceptable condition
Preventive controls are appropriate when the unsafe state is clear, serious and consistently identifiable.
Examples include:
deny disabled audit logging
deny public access to protected storage
deny permanent root access keys
deny unapproved production regions
Detective controls are useful when context is required, migration is gradual or immediate blocking would create excessive disruption.
Examples include:
report missing ownership metadata
report outdated runtime versions
report unusually broad permissions
Corrective controls can restore the required state.
Examples include:
remove public access
rotate exposed credentials
quarantine an unsafe workload
restore required logging
reconcile missing metadata
Blocking everything creates friction.
Detecting everything creates a permanent backlog.
Correcting everything automatically can create destructive surprises.
The control type should follow the risk and the confidence of the decision.
Make the governed path the easiest path
Governance is often discussed in terms of denial.
Platforms can also govern through product design.
Suppose the bfstore platform exposes:
apiVersion: platform.bfstore.dev/v1alpha1
kind: ObjectStore
metadata:
name: product-images
spec:
environment: production
profile: application-assets-v1
dataClassification: confidential
The platform applies:
public access:
blocked
encryption:
enabled
logging:
enabled
ownership:
derived from service catalog
retention:
application-assets-v1
placement:
approved production region
The user chooses meaningful product properties.
The platform derives an approved implementation.
Policy verifies the mandatory boundaries.
USER CHOOSES
meaningful product properties
PLATFORM DERIVES
approved implementation
POLICY VERIFIES
mandatory boundaries
This is governance through product design.
The secure route becomes the easiest route.
Reusable paths become the unit of assurance
A golden path can package:
- approved infrastructure
- standard identity
- telemetry
- security controls
- ownership metadata
- lifecycle automation
A security or architecture team does not need to inspect every ordinary deployment manually.
It can review, test and approve the reusable path that creates them.
The unit of assurance moves from:
every individual resource
to:
the reusable path that creates them
That is one of the most important scaling advantages of platform engineering.
Approved paths need lifecycle rules
A reusable path should not remain approved forever because it passed one review.
Each path should have:
- a named owner
- a version
- eligibility criteria
- control tests
- known limitations
- an assurance schedule
- conditions that suspend its approved status
A path may need suspension when:
- a provider changes underlying behaviour
- an incident reveals an unmodelled failure
- a control produces false negatives
- restore evidence becomes stale
- an embedded runtime reaches end of support
Assurance of the path must be continuous.
Metadata should produce action
Governance often requires:
owner
environment
cost-centre
data-classification
These values are useful only when systems consume them.
Ownership metadata can support:
- incident routing
- access review
- lifecycle management
- cost reporting
- decommissioning
- policy selection
The platform should derive metadata when an authoritative source already exists.
A populated owner field is not enough.
The governance system should know whether:
- the team still exists
- the ownership record is current
- an escalation route exists
- the mapping can be changed only by authorised people
- an unowned resource triggers remediation
Governance should create evidence, not transcription work.
Cost and data choices should be understandable
A platform can expose approved profiles:
database:
profile: production-standard-v2
The profile may publish:
availability:
multi-zone
backup:
enhanced
estimated monthly range:
£X–£Y
main cost drivers:
storage
throughput
network transfer
estimate date:
2025-03-01
A range with assumptions is more honest than a precise number the platform cannot guarantee.
Data classification can similarly select control profiles:
dataClassification: confidential
That classification may trigger:
- encryption
- restricted access
- retention rules
- audit logging
- backup controls
- region restrictions
The vocabulary should remain small and understandable.
Where classification affects material risk, the data owner may need to validate it.
The platform can translate a classification into controls.
It cannot always determine the correct classification from infrastructure intent alone.
Govern the governance system
Central controls have central blast radius.
A faulty organisation-wide policy can block development, staging and production at once.
A policy is executable architecture.
It should use the same disciplines as application and platform changes:
- source control
- peer review
- automated tests
- staged rollout
- observability
- rollback or forward repair
A safer lifecycle may be:
DRAFT
│
▼
ADVISORY
│
▼
WARNING
│
▼
ENFORCED IN NON-PRODUCTION
│
▼
ENFORCED IN PRODUCTION
Advisory mode can reveal:
- affected resources
- false positives
- migration effort
- likely exceptions
- platform gaps
Warnings can tell users when enforcement will begin.
This prevents the governance programme from discovering its assumptions by breaking production.
Tests should describe real actions
A policy test should do more than verify that a document parses.
Suppose the policy intends to deny public storage.
A useful test attempts:
create private bucket:
expected allowed
create public bucket:
expected denied
read existing private bucket:
expected allowed
delete protected log bucket:
expected denied
Tests should cover:
- allowed paths
- denied paths
- expected error messages
- exception roles
- policy interactions
- rollback behaviour
- end-to-end recovery journeys
Individually reasonable policies can conflict.
A policy that blocks public endpoints and another that requires an approved public health endpoint may be valid separately and incompatible together.
Testing realistic bundles is therefore as important as testing one rule in isolation.
Every policy needs an owner
The owner should understand:
- the risk being controlled
- the affected users
- the enforcement mechanism
- the exception process
- the evidence
- the review schedule
A policy without an owner can remain in force long after its purpose disappears.
Ownership should not mean one team writes rules in isolation.
Affected users and implementers need input.
The policy owner remains accountable for keeping the control useful, proportionate and understandable.
Handle authority and variation deliberately
Identity governance should begin with roles and responsibilities.
PERSON
│
▼
GROUP
│
▼
ROLE OR PERMISSION SET
│
▼
ACCOUNT OR PLATFORM SCOPE
This is easier to review than accumulating individual permissions.
Temporary elevation is better than standing authority
Some work requires powerful access.
Examples include:
- incident response
- recovery
- sensitive production maintenance
- organisation-policy changes
Temporary elevation can require:
- reason
- approval
- multi-factor authentication
- limited duration
- session logging
- post-action review
The organisation governs the dangerous moment rather than forcing every harmless moment to resemble one.
Exceptions and break-glass access are different
A policy exception is a planned decision to operate outside the ordinary rule.
EXCEPTION
planned, scoped and time-bounded
variation from policy
Break-glass access is an urgent recovery path.
BREAK GLASS
emergency authority used
to contain or recover from an incident
They should not share one vague workflow.
An exception should record:
- owner
- reason
- bounded scope
- compensating controls
- expiry
- review date
Break-glass use should record:
- incident
- authority
- action
- session evidence
- revocation
- post-incident review
An exception is not a policy failure.
An invisible, permanent exception is.
Exception volume is product evidence
Repeated exceptions may reveal:
- a missing product tier
- an unrealistic default
- poor documentation
- a genuine special case
- an architectural constraint
REPEATED EXCEPTION
│
▼
PRODUCT SIGNAL
│
├── expand supported path
├── improve guidance
├── change control
└── preserve exception
Governance should learn from friction.
Otherwise the exception queue becomes a permanent shadow platform.
Treat governance as an observable internal product
Evidence should be produced continuously.
CONTROL EXECUTION
│
▼
MACHINE-READABLE RESULT
│
▼
CENTRAL EVIDENCE
Useful evidence may include:
- policy evaluations
- infrastructure plans
- identity assignments
- configuration history
- exception records
- access events
- backup and restore-test results
The evidence should be:
- attributable
- tamper-resistant
- retained according to policy
- queryable
- protected from the workload or administrator under investigation
- subject to privacy and access controls
Execution evidence is not effectiveness evidence
A record that a control ran does not prove that the risk is controlled.
CONTROL EXECUTION EVIDENCE
The encryption policy evaluated
and returned allow.
CONTROL EFFECTIVENESS EVIDENCE
Protected production data remained encrypted,
including resources created outside
the primary delivery path.
Likewise:
- an owner tag does not prove the owner is current
- a backup report does not prove restoration works
- an exception record does not prove compensating controls operated
- an access review does not prove excessive authority was removed
The governance lifecycle therefore needs:
PRINCIPLE
│
▼
POLICY
│
▼
CONTROL
│
▼
EXECUTION EVIDENCE
│
▼
EFFECTIVENESS TEST
│
▼
REVIEW AND IMPROVEMENT
Feedback is part of the control
Weak feedback:
AccessDenied
Stronger feedback:
Production object stores must block public access.
Field:
spec.publicAccess
Requested:
enabled
Supported value:
disabled
Exception path:
platform-policy/production-public-access
A control that merely says no creates support tickets.
A control that explains the boundary teaches the user and preserves flow.
Policy error messages are part of the platform interface.
Governance needs service objectives
Possible SLOs include:
99% of standard platform requests
receive an automated policy decision
within one minute.
95% of exception requests
receive an initial decision
within two working days.
99% of policy denials include
an actionable remediation message.
The organisation should also measure:
- exception volume
- false-positive rate
- manual-review rate
- recurring support questions
- policy-related deployment failures
- time to remediate detected conditions
- control-effectiveness failures
The goal is not governance activity.
It is governed outcomes.
A bfstore governance path
Suppose a team requests a production object store:
apiVersion: platform.bfstore.dev/v1alpha1
kind: ObjectStore
metadata:
name: product-images
spec:
profile: application-assets-v1
environment: production
dataClassification: confidential
The platform:
derives ownership
selects the approved region
enables encryption
blocks public access
applies retention
enables audit evidence
Policy evaluates the resulting plan.
Decision:
allowed
Policy bundle:
production-storage-v4
Evidence:
stored centrally
If the team requests public access, the standard path denies it with an explanation and an exception route.
If similar approved exceptions recur, the platform team may create a supported public-assets profile with explicit eligibility and controls.
The path is then tested, versioned and reviewed like any other product.
DEVELOPER INTENT
│
▼
PLATFORM DEFAULTS
│
▼
POLICY AND CONTROLS
│
▼
EVIDENCE
│
├── compliant ──► deliver
└── exception ──► deliberate decision
│
▼
REVIEW AND LEARN
The developer does not need to assemble a temporary parliament.
The organisation still retains control over data, cost, access and evidence.
Questions I now ask
Outcome
Which organisational outcome
and risk are being addressed?
Ownership
Who owns the decision
and the policy?
Decision
Is this a settled rule
or contextual judgement?
Control
Should the system prevent,
detect or correct?
Product
Can the platform make
the compliant outcome automatic?
Evidence
What demonstrates both execution
and effectiveness?
Variation
How are exceptions, expiry
and emergency authority handled?
Learning
How will friction and failures
change the control?
These questions help distinguish governance from rule accumulation.
The mental model I am keeping
My earlier model was:
CLOUD GOVERNANCE
policies
approvals
audits
restrictions
The stronger model is:
ORGANISATIONAL OUTCOME
│
▼
DECISION RIGHTS AND POLICY
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
SAFE DEFAULTS CONTROLS OWNERSHIP
│ │ │
└─────────────────┼─────────────────┘
▼
ORDINARY DELIVERY
│
┌─────────────┴─────────────┐
│ │
▼ ▼
COMPLIANT EXCEPTION
│ │
▼ ▼
EVIDENCE HUMAN JUDGEMENT
│ │
└─────────────┬─────────────┘
▼
ASSURANCE AND LEARNING
Cloud governance should not require every developer to become an expert in organisational policy.
It should not require security, finance, networking and platform teams to approve every routine resource manually.
It should decide which outcomes matter, encode settled controls into delivery, measure whether those controls work and change them when reality disagrees.
Human attention should remain available for:
- unusual risk
- new architecture
- meaningful exceptions
- conflicting priorities
- policy evolution
- emergency recovery
The strongest governance system is not the one with the most approvals. It is the one that lets ordinary safe work move quickly, makes unsafe work difficult and gives exceptional work a clear path through deliberate human judgement.
The goal is not to remove governance from engineering.
It is to stop governance becoming a separate machine that engineers must feed before the real work can begin.