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 SaaS, PaaS, and IaaS 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 SaaS 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 SaaS app’s admin — those are operational. This module captures the governed posture around your usage.

What lives in the module

Seven record types:

Cloud service captures one cloud service used: kind (SaaS, PaaS, IaaS), provider, business purpose, owner.
Cloud service adoption captures the governed adoption decision for a service: scope, rationale, approver.
Cloud tenant account captures one tenant/account/subscription: the identifier, the owning team, the residency.
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.
Key ownership record captures who holds the cryptographic keys protecting data in the service (provider-managed, customer-managed via BYOK, customer-held HSM).
Exit/portability record captures the documented exit plan for a service: what data needs to come out, in what format, with what assistance from the provider.

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 SaaS 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 IaaS+PaaS usage).
The mobile app backend (on the same cloud).
A SaaS CRM used by dealers globally.
A SaaS engineering collaboration tool.
A SaaS parts logistics platform.
A supplier collaboration portal (vendor SaaS).
A SaaS HR system.

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

Step 2: tenant accounts. Each AWS account, Azure tenant, SaaS 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.

Seven top-level tabs: Cloud Services, Adoptions, Tenant Accounts, Shared-Responsibility, Residency Assessments, Key Ownership, Exit/Portability.

Every change is captured in the workspace Audit Log.

Common workflows

Adopting a new cloud service

Adoptions → New adoption. Capture the proposed service, the business purpose, the rationale.
Route for approval through the cloud governance process.
On approval, create the cloud service record, tenant account record, shared-responsibility record, residency assessment, key ownership record, and exit/portability record.

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.

Documenting an exit plan

Exit/Portability → New. Capture the data scope, target format, provider assistance, expected duration.
Schedule periodic exit-readiness reviews to validate the plan.

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.