Glossary
Cloud governance
Cloud governance is the set of policies, decision rights and enforcement controls that determine how an organization's cloud resources are created, accessed, secured and paid for. It connects written rules to the technical controls that apply them and to the records that prove those controls worked.
Why cloud governance matters for data at scale
Self-service is what makes cloud attractive, and it is also what makes it hard to control. Any team with an account can create storage in any region, open it to any network and keep data in it indefinitely. For an organization holding petabytes of customer, research or regulated data across several clouds and sites, each of those choices has legal, security and cost consequences. Governance is the layer that decides in advance which choices are allowed and makes the platform enforce them, so that compliance does not depend on every engineer remembering every rule.
Policies, controls and evidence
Governance works in three layers, and auditors examine all three.
- A policy is a written rule, such as "customer data is stored only in EU regions".
- A control implements the rule, such as a configuration that rejects requests to create storage elsewhere.
- Evidence shows the control operating over time, such as logs of rejected requests and periodic configuration reports.
Controls are grouped by when they act. Preventive controls block a non-conforming change before it happens. Detective controls find it afterwards, through configuration scans and log alerts. Corrective controls reverse or contain it, for instance by re-enabling encryption on a bucket where it was switched off. Organizations commonly map their controls to frameworks such as ISO/IEC 27001 or the NIST Cybersecurity Framework, and providers publish attestations, such as a SOC report, that cover the provider's side of the arrangement only.
Domains a governance model covers
| Domain | Questions the rules settle | Typical controls |
|---|---|---|
| Identity and access | Who can create, change or read which resources | Roles, permission boundaries, multi-factor authentication |
| Data location | Where data may be stored and which law applies | Region restrictions, residency rules per namespace |
| Retention | How long data is kept and when it is deleted | Lifecycle rules, retention locks, legal holds |
| Cost | Who can spend, how much, on what | Budgets, quotas, mandatory tags |
| Change | How changes are made and recorded | Infrastructure as code, approvals, audit logs |
Rules are inherited down the platform's hierarchy of organization, folders or units, and accounts or projects, so a restriction set at the top applies to everything beneath it. Increasingly the rules are written as policy as code and checked twice: in the deployment pipeline before a change is applied, and against running resources to catch drift. The cost domain overlaps with cloud cost management.
What cloud governance means for multi-site and sovereign storage
Location rules carry the most legal weight. Data residency concerns where data physically sits; data sovereignty concerns which jurisdiction's law can reach it, which may differ from where it sits. For an architect placing petabytes across regions, clouds and on-premises sites, a residency rule is only as strong as the weakest copy: a replica, a cache, a backup or a tiered archive in the wrong place breaks it just as surely as the primary would.
Retention is where governance meets storage behaviour directly. A policy that records are kept for seven years is enforced by lifecycle rules and retention locks on the buckets that hold them, and the opposite policy, that personal data is deleted after a set period, is enforced by expiration rules. Both have to hold on every copy, including replicas on other sites.
Evidence volume grows with the estate. Audit logs for a large object store run to billions of events, and keeping them in a separate system, out of reach of administrators of the storage itself, is what makes them credible to an auditor. Governance at this scale is as much a logging and retention problem as a policy problem.
Provider guardrails stop at the provider. Organization-level policies in one public cloud do not apply to another cloud or to on-premises storage, so hybrid estates end up with separate enforcement points that each need to express the same rules.
Exceptions need an owner and an end date. Large estates always carry some: a temporary permission for a migration, a bucket in a non-standard region for a pilot. Recorded with an expiry, they stay reviewable. Left open, they become the gaps an audit finds years later.
Governance controls in Scality storage
Scality ADI offers on-premise, air-gapped and sovereign-cloud deployment, with what Scality describes as "policy-enforced data residency at the namespace level". RING supports S3 Object Lock in governance and compliance modes, with retention periods and legal holds. Governance-mode retention can be lifted by an identity holding s3:BypassGovernanceRetention that sends x-amz-bypass-governance-retention:true, whereas compliance mode resists every user, the account root included, until the retain-until date. For evidence collection, ARTESCA forwards its audit logs to Splunk, Graylog, Elasticsearch or syslog.