Cloud Governance

The Cloud Governance module is the governance layer for your organization’s use of cloud services. Cloud services adopted, cloud tenant accounts, shared-responsibility records, data residency assessments, key ownership records, exit and portability records: each is one record type capturing the governed posture of your cloud footprint.

This module is not about Novantra’s own cloud deployment. It’s about your customer-side cloud usage: the managed cloud, platform, and infrastructure services your organization consumes, and the governance posture around each.

When you would reach for this

You set up cloud governance when:

A regulator or framework expects a documented inventory of cloud services in use with their shared-responsibility posture.
New cloud service adoptions need governed decision records.
Data residency for cloud-hosted data needs an audit trail.
Cryptographic key ownership for cloud-hosted data (provider-managed vs customer-managed) needs explicit records.
Exit and portability planning for cloud services needs to be documented and reviewed.
Cloud tenant accounts (your AWS account, your Azure tenant, your GCP project, your managed cloud subscriptions) need a governance register distinct from the provider’s own console.

You don’t reach for this for the cloud provider’s runtime. AWS Console, Azure Portal, GCP Console, the managed cloud app’s admin: those are operational. This module captures the governed posture around your usage.

What lives in the module

The module’s record types:

Cloud service captures one cloud service used: kind (managed cloud, platform, infrastructure), provider, business purpose, owner.
Shared-responsibility record captures the shared-responsibility model documented for one service: what the provider handles, what the customer handles, where the line sits.
Residency assessment captures a structured assessment of where data sits (and is processed) for a service.

The module also defines record types for cloud service adoptions (the governed adoption decision: scope, rationale, approver), cloud tenant accounts (the identifier, owning team, residency), key ownership records (who holds the cryptographic keys protecting data in the service), and exit/portability records (the documented exit plan: what data comes out, in what format, with what provider assistance).

A worked example: an automotive manufacturer governs its connected-car cloud platform

A global automotive manufacturer runs a connected-car platform on a cloud provider, plus uses many managed cloud services for engineering, customer relationship management, parts logistics, and supplier collaboration. Vehicles in the field stream telemetry, owners use a mobile app, dealers use a service portal. Each cloud touchpoint has governance implications: data residency, key ownership, regulatory reporting, customer expectations. The cloud governance lead, Mei, sets up Cloud Governance like this.

Step 1: inventory cloud services. Mei catalogues the services in use:

The connected-car platform on AWS (their largest infrastructure and platform usage).
The mobile app backend (on the same cloud).
A managed cloud CRM used by dealers globally.
A managed cloud engineering collaboration tool.
A managed cloud parts logistics platform.
A supplier collaboration portal (vendor managed cloud).
A managed cloud HR system.

Each cloud service is recorded with its kind, provider, business purpose, owner.

Step 2: tenant accounts. Each AWS account, Azure tenant, managed cloud subscription is registered. The connected-car platform spans multiple AWS accounts for environment separation and regional residency.

Step 3: shared-responsibility records. For each significant service, the shared-responsibility model is documented: which controls the provider operates, which the customer operates. This is the foundation for understanding what the manufacturer must do versus what they inherit.

Step 4: residency assessments. Vehicle telemetry from cars in Region X must stay in Region X. Mei runs residency assessments per service: where does the data sit at rest, where is it processed, where are backups, where are logs. Findings (data flowing to unexpected regions, backup posture not aligned) become Findings.

Step 5: key ownership records. For the connected-car platform’s customer data, the manufacturer holds the encryption keys via BYOK. For the CRM and the supplier portal, the keys are provider-managed (with documented acceptance). For payroll data in the HR system, customer-held keys via the provider’s BYOK feature. Each record captures the posture and the rationale.

Step 6: exit/portability records. For each service, Mei records the exit plan: what data needs to come out if the manufacturer leaves, in what format, with what assistance contractually required from the provider, how long the migration would take. Periodic exit-readiness tests validate the plan still works.

After a year:

The cloud footprint is inventoried.
Shared responsibility is documented per service.
Residency posture is auditable.
Key ownership is explicit per service.
Exit plans are documented and reviewed.

What you’ll see in the product

Cloud Governance lives under Governance -> Cloud Governance in the workspace.

Top-level tabs: Cloud Services, Shared-Responsibility, Residency Assessments, Service Adoptions, Tenant Accounts, Key Ownership, Exit & Portability.

Each tab supports record creation, detail review, update, and archive for the records owned by this module. These actions record governance posture only: the module does not run provider account changes, IAM changes, key operations, exports, backups, or provider control-plane automation.

Every change is captured in the workspace Audit Log.

Common workflows

Recording a service adoption

Service Adoptions -> New. Capture the proposed service, scope, purpose, rationale, decision posture, and supporting references.
Link the record to a cloud service, shared-responsibility record, or residency assessment when those references exist.
After approval, document the shared-responsibility record and run a residency assessment for the service.

Registering a cloud tenant account

Tenant Accounts -> New. Capture the provider account, tenant, project, or subscription reference, the owner, the environment, and any residency or responsibility boundary.
Use the record as a governance anchor for the account. Provider IAM, billing, and console operations remain in the cloud provider’s own control plane.

Recording key ownership

Key Ownership -> New. Capture who owns or controls the keys, what the provider controls, what the customer controls, and which evidence references support the posture.
Keep KMS setup, rotation, rewrap, and recovery operations in the owning key-management or cryptography surfaces. This record describes the posture; it does not operate the key.

Recording exit and portability posture

Exit & Portability -> New. Capture the data scope, export formats, provider assistance, migration constraints, and exit-test evidence.
Review the plan periodically. This module records the posture; it does not run exports, backups, or database handoff.

Reviewing residency

From a cloud service, conduct a residency assessment.
Capture data-at-rest location, processing location, backup location, log location.
Raise findings for any misalignment with policy.

Party Engagements - cloud providers are typically party engagements too.
Cryptography - key ownership records intersect with cryptographic governance.
Assets - cloud services may be asset records.
Risks - cloud concentration and residency risks live in the risks register.
Findings - posture misalignments are findings.