Access
Governs tenant identity, authentication, authorization, privilege, service accounts, delegated administration, and review.
Explore Access →ThreatKrusher Pillar 05 · Governed cloud operations
Operate cloud tenants and collaboration through controlled configuration and change.
ThreatKrusher Cloud connects tenant ownership, identity, administrative authority, configuration baselines, data and sharing boundaries, monitoring, change, vendor dependencies, lifecycle, and review.
The cloud operating problem
Provider availability does not govern your tenant.
Cloud platforms supply native capabilities, but the customer still owns decisions about configuration, identity, sharing, data, applications, vendors, retention, recovery, monitoring, and acceptable risk.
- Tenant ownership, emergency contacts, and administrative authority are unclear.
- Default or legacy settings drift from the approved operating baseline.
- External sharing, guest access, applications, and integrations expand without review.
- Data classification, location, retention, deletion, and backup assumptions are undocumented.
- Changes happen through portals and scripts without tickets, approval, testing, or rollback.
- Vendor-native security and uptime are mistaken for complete customer governance and resilience.
Scope boundary
Define which tenants, services, workloads, and decisions are managed.
Included when contracted
- Tenant and supported-service inventory
- Administrative roles and configuration baselines
- Identity, collaboration, sharing, and application governance
- Change, monitoring, incident, and remediation workflows
- License, vendor, integration, and lifecycle coordination
- Configuration, activity, review, and evidence records
Not implied
- Support for every cloud provider, tenant, workload, app, or integration
- Guaranteed provider availability, performance, security, or data residency
- Backup, recovery, archive, eDiscovery, or retention without explicit scope
- FedRAMP, government-cloud, sovereign-cloud, or compliance status by default
- Unlimited migration, engineering, development, or project work
- eTrepid ownership of client data or business decisions
Client assumptions
- Accurate tenants, domains, services, data, users, vendors, and ownership
- Approved data classification, sharing, retention, and residency decisions
- Named system, data, business, security, privacy, and change authorities
- Current licensing, subscriptions, contracts, and vendor cooperation
- Timely approvals, testing, communications, and business participation
- Funded migrations, remediation, integrations, and projects outside recurring scope
Cloud governance system
Six disciplines turn a tenant into a controlled operating environment.
Inventory & ownership
Know the environment
Tenant, domain, subscription, service, workload, owner, administrator, vendor, criticality, data, and dependency.
Baseline & change
Control configuration
Approved settings, version, exception, implementation path, test, change authority, validation, rollback, and review.
Identity & administration
Limit authority
Human and non-human identity, authentication, role, privilege, delegated administration, emergency access, and review.
Data & collaboration
Govern information movement
Classification, location, sharing, guest access, applications, connectors, retention, deletion, export, and ownership.
Monitoring & response
Observe operating conditions
Approved logs, health, security signals, configuration changes, incidents, vendor notices, escalation, and remediation.
Lifecycle & resilience
Manage change over time
Onboarding, migration, licensing, renewal, integration, backup dependency, recovery, offboarding, archive, and exit.
People · process · system
Cloud governance requires operating authority beyond the admin portal.
Tenant operating lifecycle
Move from discovered state to governed, reviewable operation.
01
Discover
Inventory tenants, services, domains, identities, data, applications, vendors, configurations, costs, and dependencies.
02
Decide
Approve architecture, ownership, data boundaries, baseline, sharing, access, retention, resilience, and risk.
03
Configure
Implement approved settings, roles, policies, integrations, logging, protection, and evidence through controlled change.
04
Validate
Test configuration, access, data flows, collaboration, monitoring, recovery dependencies, and documented exceptions.
05
Operate
Administer users, services, changes, incidents, vendors, licenses, integrations, records, and lifecycle activities.
06
Review
Evaluate drift, risk, sharing, privilege, health, incidents, evidence, cost, renewal, capacity, and improvement.
Evidence produced
Make the tenant state and each material change reconstructable.
Boundary
Tenant record
Tenant, domain, services, workloads, data, owner, administrators, vendors, locations, dependencies, and scope date.
State
Baseline record
Configuration, version, rationale, exception, owner, implementation, validation, evidence, and review date.
Change
Administration record
Request, authority, affected service, risk, test, action, result, rollback, administrator, timestamp, and closure.
Review
Cloud review
Drift, access, sharing, applications, incidents, capacity, cost, risk, remediation, decision, and next review.
Shared responsibility
Separate provider operation, managed administration, and client authority.
Cloud provider
- Owns and operates the native service and underlying provider boundary
- Defines supported features, APIs, regions, availability, security, and service terms
- Publishes provider-side documentation, notices, and contractual commitments
- Retains responsibility that cannot be transferred through client configuration
- May rely on additional infrastructure, software, carrier, and supply-chain parties
eTrepid performs when contracted
- Architecture, migration, configuration, and administration support
- Identity, collaboration, monitoring, change, incident, and lifecycle operations
- Vendor/platform coordination within delegated authority
- Documentation, evidence, reporting, and review workflows
- Backup/recovery administration only where expressly scoped
The client retains
- Business purpose, data ownership, classification, and acceptable use
- Legal, privacy, contractual, residency, retention, and disclosure decisions
- Architecture, risk, exception, sharing, and material change approval
- Accurate users, systems, data, vendors, and process facts
- Timely decisions, licenses, funding, participation, and third-party agreements
Critical dependencies
Cloud depends on identity, controlled service work, and security assurance.
ITSM
Operates cloud requests, incidents, changes, configuration, vendors, licenses, migrations, remediation, and lifecycle work.
Explore ITSM →Trust
Monitors cloud security conditions, configuration changes, detections, incidents, vulnerabilities, and validation evidence.
Explore Trust →Cloud proof gate
Verify platform, baseline, and responsibility claims before publication.
Public proof should use approved, redacted tenant inventories, configuration-baseline evidence, administrative-change records, sharing/access reviews, monitoring examples, migration validation, or recovery tests with scope and limitations.
Publication hold
No current supported-platform list, configuration baseline, partner authorization, tenant count, migration outcome, administrative target, backup/recovery claim, data-location statement, or client result is approved for this page. Reconcile current agreements, platform records, tenant configuration, licensing, vendor status, and delivery ownership first.
Common questions
Clarify the cloud boundary before changing the tenant.
Does the cloud provider secure everything for us?
No. Providers secure and operate defined parts of their service. Customers and their managed providers retain responsibilities for identity, configuration, data, applications, endpoints, integrations, sharing, monitoring, retention, recovery, vendors, and use according to the service and agreement.
Does cloud availability include backup and recovery?
Not necessarily. Availability, retention, recycle or version features, backup, archive, legal hold, disaster recovery, and business continuity solve different problems. Required recovery outcomes and supporting services must be explicitly designed, contracted, implemented, and tested.
Can eTrepid guarantee where our cloud data resides?
No blanket guarantee is made. Data location can depend on provider, service, tenant type, region, configuration, support, telemetry, backup, subprocessors, users, integrations, and contractual terms. Requirements need service-specific verification.
Can we keep our current tenant configuration?
Potentially, after ownership, baseline, risk, supportability, data, identity, integrations, exceptions, monitoring, recovery, and service impact are evaluated. Accepted exceptions and required remediation must be documented.
Cloud operations
Start with the tenants, data boundary, critical services, administrative authority, and desired operating model.
Provide only non-sensitive context about cloud providers, tenants, workloads, users, collaboration, current ownership, business trigger, recurring pain, migration or governance needs, and timing.