Purpose

This standard defines the requirements for Azure subscription design, classification, governance, ownership, provisioning, operational management, and lifecycle management within University-managed Azure environments.

Azure subscriptions provide administrative, operational, financial, governance, and accountability boundaries for cloud resources and workloads. Subscriptions also serve as the primary workload-isolation boundary when required by workload classification, risk, regulatory obligations, operational requirements, or approved architecture decisions.

Governance requirements applicable to subscriptions must be implemented through approved Management Group structures, policy assignments, architecture controls, platform automation, and operational processes.

Scope

This standard applies to Azure subscriptions created, governed, operated, or otherwise managed through approved University governance processes, including:

• Production subscriptions
• Non-production subscriptions
• Regulated workload subscriptions
• Enterprise workload subscriptions
• Innovation and sandbox subscriptions
• Shared services subscriptions
• Platform subscriptions
• Application subscriptions
• Data platform subscriptions

Azure subscriptions used for University business must not be created or operated outside approved University governance processes.

Requirements

1. Subscription Boundary

Azure subscriptions must provide defined administrative, operational, financial, governance, and accountability boundaries for the resources and workloads they contain.

Subscription boundaries must align with workload ownership, workload classification, operational responsibility, security requirements, cost accountability, and applicable legal, regulatory, contractual, grant, and institutional obligations.

A subscription boundary does not replace resource-level identity, network, data protection, monitoring, resilience, or operational controls.

2. Approved Management Group Placement

Every subscription must be assigned to an approved Azure Management Group.

Management Group placement must align with the subscription classification, workload classification, hosting requirements, governance requirements, and operational model.

Subscriptions must inherit applicable policy assignments, security guardrails, monitoring requirements, and governance controls through approved Management Group hierarchies whenever practical.

Direct subscription-level governance configuration must be minimized when equivalent controls can be managed and inherited through an approved Management Group.

3. Workload Isolation

Workloads requiring distinct governance, ownership, administration, security controls, regulatory controls, operational management, billing accountability, or risk treatment must be evaluated for deployment into dedicated subscriptions.

Regulated workloads must be deployed into subscriptions aligned with approved regulated-workload hosting architectures and applicable workload-classification requirements.

Workloads with materially different classifications or incompatible governance requirements must not share a subscription unless the combined requirements can be implemented without weakening required controls or creating unacceptable operational risk.

Production and non-production workloads must be separated when required by workload classification, data sensitivity, access requirements, change processes, deployment controls, operational risk, or applicable obligations.

4. Subscription Classification

Every subscription must be assigned an approved subscription classification before workloads are deployed.

Approved subscription classifications may include:

• Platform
• Shared Services
• Enterprise
• Regulated
• Innovation
• Sandbox

Subscription classification must align with the workloads hosted in the subscription, applicable workload classifications, governance requirements, operational responsibilities, and approved hosting architecture.

A subscription containing workloads with different classifications must satisfy the requirements of the most restrictive applicable classification unless an approved architecture defines an alternative control model.

Changes to subscription purpose, hosted workloads, data, ownership, or applicable obligations must trigger reevaluation of the subscription classification and Management Group placement.

5. Environment Separation

Separate subscriptions for development, testing, and production environments are not required unless justified by workload classification, regulatory requirements, governance requirements, risk management requirements, or operational separation requirements. Subscriptions must identify the environment purpose of the workloads they host.

Environment designations may include:

• Production
• Non-production
• Development
• Testing
• Quality assurance
• Recovery
• Innovation
• Sandbox

A subscription may support more than one non-production environment when the arrangement satisfies applicable isolation, access, data protection, operational, and governance requirements.

Production workloads must not be deployed into subscriptions designated solely for innovation, experimentation, or sandbox use.

Regulated data must not be used in non-production, innovation, or sandbox subscriptions unless the subscription and environment satisfy all applicable hosting, protection, monitoring, access, and lifecycle requirements.

6. Ownership Assignment

Every subscription must have documented ownership before resources or workloads are deployed.

Required ownership information must include:

• Business Owner
• Technical Owner
• Operational Support Owner
• Cost Accountability Owner
• Data Owner when applicable
• Security Contact when applicable

One person or organizational role may fulfill more than one ownership responsibility when appropriate.

Ownership responsibilities must be assigned to current University personnel, approved organizational roles, or accountable University units.

Ownership information must remain current throughout the subscription lifecycle and must be updated when organizational, staffing, support, funding, or workload responsibilities change.

Subscriptions without valid ownership must be assigned for remediation, restricted from further deployment, or evaluated for retirement.

7. Metadata and Tagging

Subscriptions and supported resources must implement approved metadata and tagging requirements.

Required metadata must support:

• Ownership identification
• Cost accountability
• Subscription classification
• Workload classification
• Environment identification
• Operational support
• Service and application identification
• Governance reporting
• Compliance reporting
• Lifecycle management

Required metadata must use approved names, values, formats, and authoritative sources.

Metadata that identifies owners, classifications, environments, costs, or support responsibilities must remain current throughout the subscription lifecycle.

Metadata requirements should be applied and validated through approved automation and governance controls whenever practical.

8. Identity and Access Management

Subscriptions must use approved enterprise identity services and access-management processes.

Administrative access must be governed through approved identity, authorization, and privileged-access controls.

Access must be assigned according to approved business need and least-privilege principles.

Role-based and group-based access assignments must be used instead of direct individual assignments whenever practical.

Administrative access must be separated from standard user access when required by the role, workload classification, risk, or applicable obligations.

Subscription-level access must be periodically reviewed and removed when the approved business or operational need no longer exists.

Workload identities, application identities, service identities, and automation identities must use approved identity mechanisms and must not rely on shared user credentials.

Emergency and recovery access must be documented and governed through approved processes when required.

9. Governance and Policy Enforcement

Subscriptions must comply with inherited and directly assigned governance controls.

Required controls must be implemented through approved policy definitions, initiatives, assignments, remediation capabilities, architecture controls, and operational processes whenever practical.

Workload and subscription teams must not disable, circumvent, replace, or materially alter inherited governance controls without approved authorization.

Noncompliant configurations must be prevented, remediated, or managed through an approved exception.

Policy exemptions, exclusions, and waivers must be documented, approved, limited in scope, assigned an accountable owner, and periodically reviewed.

10. Monitoring and Logging

Subscriptions must participate in approved enterprise monitoring, logging, alerting, and audit services.

Monitoring configurations must provide visibility appropriate to the subscription classification, hosted workloads, operational responsibilities, security requirements, and applicable obligations.

Subscription monitoring must support:

• Operational visibility
• Resource and service health monitoring
• Administrative activity monitoring
• Security visibility
• Governance visibility
• Incident detection and investigation
• Audit and compliance activities

Required activity logs, resource logs, security logs, and audit records must be collected, protected, retained, and made available through approved monitoring services.

Workload teams remain responsible for application, business-process, integration, and data telemetry not provided by subscription-level monitoring.

11. Network Integration

Subscriptions must implement approved networking and connectivity architectures.

Network configurations must support workload isolation, approved communication paths, operational visibility, traffic monitoring, and applicable security requirements.

Connectivity decisions must follow the approved risk-based connectivity model.

Ingress, egress, administrative access, service-to-service communication, shared-service connectivity, and external integrations must be identified and governed.

Public exposure must be limited to documented business requirements and protected through appropriate identity, access, network, application, monitoring, and governance controls.

Network architectures must not create unauthorized transit, route propagation, service exposure, or connectivity between subscriptions, workloads, or external services.

12. Shared Service Consumption

Subscriptions may consume approved enterprise shared services.

Shared-service consumption must not weaken required workload isolation, governance, identity, network security, monitoring, data protection, resilience, or compliance controls.

Shared services must be evaluated according to the data they store, process, transmit, expose, or can access.

Services directly handling regulated data must satisfy the applicable workload hosting requirements.

Responsibilities between shared-service providers and workload owners must be documented.

Workload teams must not assume that a shared service is approved for every workload classification, data classification, or regulatory use case.

13. Cost Management

Every subscription must have an identified cost-accountability owner.

Subscription costs must be attributable to an approved organizational unit, service, project, workload, funding source, or other accountable business purpose.

Subscriptions must implement approved cost-management capabilities appropriate to their purpose and financial model.

Cost-management capabilities must support:

• Budget visibility
• Cost allocation
• Cost reporting
• Usage accountability
• Anomaly identification
• Resource optimization

Unallocated, unexpected, or materially abnormal costs must be reviewed through approved financial and operational processes.

Unused, abandoned, oversized, or unnecessarily duplicated resources must be evaluated for remediation or retirement.

14. Resource Organization and Naming

Resources and resource groups must follow approved organization and naming requirements.

Resource-group design must align with operational ownership, deployment lifecycle, access management, workload boundaries, and resource lifecycle requirements.

Resources with materially different owners, access models, deployment lifecycles, or retirement schedules should be separated when practical.

Naming and organization must support clear identification, inventory management, operational support, automation, governance reporting, and incident investigation.

15. Deployment and Automation

Subscriptions must be provisioned and configured through approved platform automation unless an approved exception exists.

Infrastructure as Code must serve as the authoritative implementation source for managed subscription configuration.

Automation must support applicable capabilities, including:

• Subscription provisioning
• Management Group placement
• Governance and policy configuration
• Identity and access integration
• Monitoring and logging integration
• Network onboarding
• Metadata and tagging
• Cost-management integration
• Required shared-service integration
• Lifecycle management

Deployment artifacts and configuration changes must be version-controlled, reviewable, and deployed through approved processes.

Manual configuration must be minimized and reconciled with the authoritative implementation source.

Secrets, credentials, and other sensitive values must not be stored in deployment artifacts in an unprotected form.

16. Management Group Reassignment

Movement of a subscription between Management Groups must follow approved governance review and change-management processes.

Management Group reassignment must evaluate:

• Subscription and workload classification
• Governance impacts
• Security impacts
• Compliance impacts
• Policy inheritance changes
• Identity and access impacts
• Monitoring and logging impacts
• Network and connectivity impacts
• Shared-service impacts
• Operational impacts
• Cost-management impacts

Required controls must be validated before or immediately following reassignment according to the approved change plan.

A subscription must not be moved to avoid, weaken, or circumvent required governance controls.

17. Operational Management

Subscriptions must have documented operational support and escalation responsibilities.

Operational processes must address, as applicable:

• Monitoring and alert response
• Incident response
• Access administration
• Change management
• Policy and configuration remediation
• Vulnerability remediation
• Service health events
• Capacity and quota management
• Cost management
• Backup and recovery coordination
• Ownership and metadata maintenance

Subscriptions must use supported services, configurations, and deployment capabilities appropriate to their workload and subscription classifications.

Operational deficiencies must be documented, assigned to an accountable owner, and remediated through approved processes.

18. Resilience and Recovery

Subscriptions hosting workloads requiring backup, recovery, continuity, or resilience capabilities must integrate with approved recovery services and operational processes.

Recovery capabilities must align with the requirements of the hosted workloads and data.

Subscription architecture must not prevent workloads from meeting approved Recovery Time Objectives, Recovery Point Objectives, backup, restoration, continuity, or recovery requirements.

Recovery-related identities, network paths, monitoring, configuration, and dependencies must be included in applicable recovery planning and validation activities.

19. Lifecycle Management

Subscriptions must be managed through approved lifecycle processes.

Lifecycle activities include:

• Request and approval
• Classification
• Provisioning
• Configuration
• Workload onboarding
• Modification
• Operational management
• Ownership review
• Access review
• Classification review
• Governance and compliance review
• Workload offboarding
• Decommissioning
• Access removal
• Resource cleanup
• Data retention and disposition
• Subscription cancellation or retirement

Subscription status, ownership, classification, and business purpose must be periodically reviewed.

Subscriptions that are no longer required, no longer have valid ownership, or no longer serve an approved business purpose must be evaluated for retirement.

20. Decommissioning

Subscriptions must not be canceled or retired until an approved decommissioning process has been completed.

Decommissioning activities must address:

• Workload and dependency identification
• Stakeholder notification
• Data retention requirements
• Data migration when required
• Backup and recovery requirements
• Data disposition
• Resource deletion
• Access removal
• Identity and credential removal
• Network and shared-service disconnection
• Monitoring and alert retirement
• Automation and deployment-record updates
• Inventory and configuration-record updates
• Financial closure
• Final ownership approval

Applicable legal, regulatory, contractual, grant, records-management, audit, investigation, and litigation-hold requirements must be satisfied before data or evidence is destroyed.

Decommissioning evidence must be retained through approved governance processes.

21. Architecture Review

Subscription designs that deviate from approved governance structures, subscription classifications, hosting architectures, or architecture patterns require architecture review and approval before implementation.

Architecture review is also required when a proposed subscription design introduces material changes to:

• Management Group placement
• Workload isolation
• Administrative boundaries
• Identity and access models
• Network boundaries or connectivity
• Shared-service consumption
• Monitoring or audit capabilities
• Regulated workload hosting
• Automation or deployment models

Exceptions

Exceptions to this standard must follow approved architecture governance and information security exception processes.

Approved exceptions must be periodically reviewed and must not be treated as permanent architecture patterns.