Governance assembled from services, not bought as one product

The AWS assessment spends most of its time on what is genuinely coverable, because the gaps here are service boundaries rather than configuration choices.

• Coverage gaps named up front. Which stores the discovery service can reach and which need separate tooling, since object storage focus is a real limit rather than a setting.
• Dual permission model mapped. Effective access per principal across both the identity policy and the catalogue grant, because a partial migration produces both denials and over-permission.
• Evidence approach decided. Conformance packs plus a third-party evidence tool scoped realistically, given the platform's own evidence automation is in maintenance mode.
• Framework packs matched to obligations. Which shipped templates correspond to what genuinely binds you, and which of your obligations no rule can evaluate at all.
• Catalogue transition risk assessed. Where the business catalogue capability is heading, so the durable asset is your glossary and ownership records rather than a console.
• Rollup region residency. Log aggregation and rollup regions checked, since this is the layer that moves data outside Australian regions without a deliberate decision.

Catalogue and access first, because the dual permission model is the thing that goes wrong. Discovery and evidence follow, with the gaps in coverage stated rather than glossed.

• Technical metastore as the foundation. Schema and partition metadata held centrally so the access and query layers resolve against one source rather than several.
• Fine-grained grants, fully migrated. Table, column, row and cell permissions plus tag-based access control completed rather than left half-applied alongside legacy grants.
• Business catalogue with subscriptions. Domains, projects, glossary terms and request workflows so analysts find and request data without a platform ticket.
• Discovery scoped and costed. Managed and custom identifiers applied across object storage, with results retained as records usable in an investigation.
• Conformance packs at organisation scope. Framework-keyed detective controls deployed across accounts as one entity rather than configured account by account.
• Telemetry normalised into your storage. Security and access logs centralised in an open schema in buckets you own, queryable with SQL for an evidence extract.

The AWS strength here is precision of access control. The weakness is that nothing protects content once it leaves the platform, so the design has to acknowledge where governance simply stops.

• Both permission layers designed together. Identity policy and catalogue grants treated as one design problem, because a request must satisfy both and a gap in either is invisible.
• Row and column controls verified. Enforcement tested by querying as accounts at several permission levels rather than inferred from the grants that were applied.
• Workforce identity, not shared roles. Access traced to a person through permission sets rather than a shared role, so an audit entry names someone.
• Customer-managed keys throughout. Keys for governed stores and evidence repositories under your control, with key access separated from the teams being audited.
• The export boundary acknowledged. No protection travels with a downloaded file, so controls concentrate on preventing extraction rather than on protecting content afterwards.
• Retention set per source. Log retention chosen by source and scenario, since centralised telemetry grows with every account and region added.

Because governance is assembled here, the main adoption risk is a control quietly lapsing in one of the several consoles nobody has opened for a quarter.

• Ownership across several consoles. A named owner for each service in the governance stack, because assembled governance fails where responsibility is ambiguous.
• Analysts taught the request path. How to find data in the catalogue and subscribe to it, so the governed route is faster than asking someone for credentials.
• Platform team trained on both layers. The dual permission model taught explicitly, since this is the single largest source of support tickets after go-live.
• Coverage limits communicated. Which stores are outside discovery scope written down and shared, so nobody assumes the estate is fully covered.
• Evidence extract rehearsed. The auditor extract produced once before it is needed, which is when a missing log source becomes obvious.
• Runbooks per control. What to do when a conformance rule reports non-compliance, including who decides whether it is a genuine failure.

Assembled governance decays at the joins. Continuation watches the seams between services, new accounts and regions, and the parts of the platform that are being repositioned.

• Control coverage per account and region. New accounts and newly opted-in regions checked against the intended pack, since coverage varies by region and a gap is real.
• Permission drift across both layers. Identity policies and catalogue grants reviewed together, because drift in either produces over-permission that no single console shows.
• Discovery re-run as storage grows. New buckets and prefixes scanned as they appear, with anything outside service scope still tracked as a known gap.
• Service repositioning tracked. Catalogue and evidence services watched for transition, since one is already in maintenance mode and another is being folded into a studio.
• Log and retention cost reported. Centralised telemetry growth reported monthly, because it scales with account count rather than with usage.
• Residency re-verified after change. Rollup and aggregation regions re-checked whenever configuration changes, as this drift is the least visible and most asked about.