CM-5 / CM-3 / AC-3 NIST SP 800-53 Rev 5

Resource locks on production resources

Demonstrate that production resources are protected by technically enforced locks that prevent unauthorized or accidental deletion and modification, and that lock management follows documented procedures requiring privileged access and change approval.

Description

What this control does

Resource locks are protective mechanisms applied to critical production infrastructure (virtual machines, databases, networks, storage accounts) to prevent accidental or unauthorized deletion and modification. Locks are typically implemented at the cloud provider level (Azure Resource Manager locks, AWS Service Control Policies with denial statements, GCP Organization Policy constraints) or through infrastructure-as-code enforcement. This control ensures that production resources cannot be deleted or altered without first removing the lock, which itself requires elevated privileges and typically follows a formal change management process. Resource locks act as a last line of defense against human error, rogue automation, and privilege abuse.

Control objective

What auditing this proves

Associated risks

Risks this control addresses

Accidental deletion of production databases or compute instances by authorized administrators during routine maintenance activities
Malicious deletion of critical infrastructure by compromised administrator accounts or insider threats
Automated scripts or infrastructure-as-code pipelines unintentionally destroying production resources due to misconfiguration or scope errors
Cascading resource deletion triggered by removal of parent resource groups or organizational units without proper protection
Unauthorized modification of production network security groups, firewall rules, or routing tables leading to service disruption or data exposure
Ransomware or destructive malware with elevated privileges systematically deleting cloud resources to maximize business impact
Rapid uncontrolled infrastructure changes during incident response that inadvertently destroy forensic evidence or worsen outages

Testing procedure

How an auditor verifies this control

Obtain and review the organization's resource lock policy documenting which resource types, environments, and naming patterns require locks and the authorized lock management procedures
Generate an inventory of all production resources from cloud provider management consoles, APIs, or configuration management databases, categorized by resource type and environment tag
Query the cloud provider's lock configuration via CLI, API, or governance dashboard to enumerate all active resource locks, their types (ReadOnly vs CanNotDelete), scope (resource, resource group, subscription), and assigned resources
Compare the lock inventory against the production resource inventory to identify resources that should have locks but do not, documenting exceptions with business justification
Select a representative sample of 10-15 production resources spanning different types (compute, database, network, storage) and verify lock presence through direct console inspection and configuration export
Review access control policies and role assignments governing who can create, modify, or remove resource locks, confirming that lock management requires roles equivalent to Owner or Resource Lock Contributor and is not delegated to service accounts or operational teams
Examine change management tickets and approval records from the past 12 months related to lock removal or modification, verifying that each followed documented procedures including business justification and re-application after maintenance
Test lock enforcement by attempting to delete or modify a non-critical locked resource in a controlled test environment using an account with typical administrative privileges but without lock management permissions, confirming the operation is blocked with appropriate error messaging

Evidence required Configuration exports from cloud provider APIs showing lock assignments, types, and scope for production resources (Azure: Get-AzResourceLock output; AWS: SCP and tagging enforcement policies; GCP: Organization Policy constraints). Screenshots or CLI output demonstrating lock presence on sample resources and access denial when deletion is attempted by non-privileged accounts. RBAC policy documents and role assignment reports showing separation between operational resource management and lock administration. Change management tickets with timestamps, approvers, and justifications for lock removal events in the audit period.

Pass criteria All production resources defined in the resource lock policy have appropriate locks applied (CanNotDelete or ReadOnly as specified), lock management permissions are restricted to privileged roles requiring multi-person approval or MFA, no unauthorized lock removals occurred during the audit period, and lock enforcement successfully prevents deletion or modification by accounts without lock management privileges.

Where this control is tested

Audit programs including this control

Azure Tenant Hardening

Tenant-wide hardening for Azure subscriptions — identity, networking, logging and Defender for Cloud baseline.