Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1

Maintain approved audit and assurance policies, procedures and standards that are documented, communicated to the staff they bind, applied in practice, and reassessed at least once a year.

• The signed audit and assurance policy showing an approval authority and an effective date
• The annual review record with reviewer, date and outcome
• Distribution or acknowledgement evidence showing the policy reached audit and assurance staff
• The audit standards the organisation has adopted, named in the policy

• Policy exists but has not been reviewed inside the last twelve months
• Approval is undated or by someone without the authority to approve it
• No evidence the policy was ever communicated beyond the team that wrote it

Commission audit and assurance assessments from assessors independent of the activity being examined, run them against recognised standards, and repeat them at least annually.

• Assessment reports from the last twelve months naming the assessor
• Evidence of assessor independence such as an engagement letter or organisational chart showing separation
• The recognised standard each assessment was performed against
• Scope statement for each assessment

• Assessment carried out by the same team that operates the controls
• No assessment inside the last twelve months
• The standard assessed against is not named, so the result cannot be interpreted

Drive the scope and frequency of independent assessments from a documented risk assessment, so higher risk systems and processes are examined more often than lower risk ones.

• The risk-based audit plan with the risk rating behind each entry
• The risk assessment or register the plan was derived from
• Evidence the plan was approved and then followed, such as completed engagements matched to planned ones
• Records of plan changes when risk ratings moved

• An audit plan that lists the same scope every year with no risk input
• Risk ratings recorded but not reflected in assessment frequency
• Plan approved and then not followed, with no record of why

Confirm during each audit that the organisation meets every standard, regulation, contract clause and statutory obligation inside the audit scope, and record the outcome for each one.

• The compliance obligations register mapped to the audit scope
• Audit working papers showing a tested conclusion against each obligation
• Non-conformity records raised where an obligation was not met
• Contractual clauses that carry security or compliance obligations

• Obligations register is out of date so newly applicable regulation was never audited
• Audit report gives an overall opinion with no per-obligation conclusion
• Contractual obligations treated as out of scope for the compliance audit

Run a defined audit management process covering planning, risk analysis, control assessment, conclusions, remediation timetables, report production, and re-examination of earlier reports and their supporting evidence.

• The documented audit management process with its stages and owners
• A completed audit file showing every stage was worked through
• Remediation schedules produced from audit conclusions
• Evidence that previous reports and their supporting evidence were revisited

• Process documented but audits run informally around it
• Prior-report review step skipped, so repeat findings are never identified as repeats
• Conclusions recorded without the supporting evidence being retained

Track every audit finding on a risk-prioritised corrective action plan with named owners and due dates, and report remediation progress to the stakeholders accountable for closing it.

• The corrective action plan showing risk priority, owner and target date per finding
• Status reports issued to accountable stakeholders
• Closure evidence for findings marked complete
• Records of due-date extensions and who approved them

• Findings recorded but with no owner or no due date
• Overdue findings rolled forward silently without re-approval
• Closure claimed with no evidence that the underlying weakness was fixed

Keep an approved application security policy set that directs how applications are planned, delivered and supported, communicate it to development and operations staff, and refresh it at least annually.

• The approved application security policy with approver and effective date
• The annual review record
• Evidence the policy reached development and operations teams
• Supporting standards the policy points to, such as a secure coding standard

• Policy written for a previous development model and never updated for current delivery practice
• Development teams unaware the policy exists
• Annual review missed

Define and keep current the minimum security requirements each class of application must satisfy before it is built or released.

• Documented application security baselines per application class
• Evidence baselines are checked before release, such as a gated checklist
• A change history showing baselines being updated
• Named owner for each baseline

• One generic baseline applied to application types with very different risk
• Baselines documented but never enforced at release
• Baseline last updated years ago and no longer reflects the current stack

Measure application security with technical and operational metrics that tie back to business objectives, security requirements and compliance obligations.

• The defined application security metric set with each metric traced to an objective or obligation
• Recent metric reports and the audience they went to
• Thresholds or targets set against each metric
• Evidence metrics drove a decision or action

• Metrics collected because the tool produces them, with no link to any objective
• Reports produced but never read by anyone who can act
• No target, so the metric cannot say whether performance is acceptable

Build applications through a secure development lifecycle so the organisation's security requirements are applied at design, build, deployment and operation.

• The documented secure development lifecycle with security activities at each stage
• Design review or threat model records for recent applications
• Evidence of security requirements being carried into build and deployment
• Records showing the lifecycle applied to a real project end to end

• Security activity concentrated at the end of the lifecycle only
• Threat modelling done for flagship projects and skipped elsewhere
• Operational stage excluded, so security requirements stop at go-live

Test applications for security before release against defined acceptance criteria covering new systems, upgrades and versions, automating the testing where the delivery pipeline allows.

• The documented testing strategy with acceptance criteria for release
• Test results for recent releases, upgrades and new versions
• Pipeline configuration showing automated security tests
• Records of releases blocked or accepted against the criteria

• Acceptance criteria undefined, so a failing result does not stop a release
• Upgrades and minor versions exempted from testing
• Automated tests present but their failures are routinely overridden

Deploy applications through standardised, repeatable and policy-compliant release mechanisms, automating the deployment path wherever it is practical.

• The documented deployment standard and the tooling that implements it
• Deployment pipeline definitions showing the compliant path
• Records of deployments performed, showing the standard path was used
• Approval records for any manual deployment

• A sanctioned pipeline exists but manual deployments bypass it routinely
• Deployment configuration itself is unmanaged and drifts between environments
• No record of who deployed what, so a release cannot be traced

Operate a defined process for fixing vulnerabilities found in applications, using automated remediation where the vulnerability class allows.

• The application vulnerability remediation process with timeframes by severity
• A vulnerability backlog showing age and status per finding
• Evidence of automated remediation, such as auto-raised dependency updates
• Records of accepted risk where a vulnerability was not fixed

• Findings recorded but with no remediation timeframe by severity
• Long-lived backlog of high severity application findings with no risk acceptance
• Automated fixes raised but never merged

Keep approved business continuity and operational resilience policies and procedures, communicate them to the people who must act on them, and review them at least once a year.

• The approved continuity and resilience policy with approver and date
• Annual review record
• Evidence of communication to response teams and business owners
• The procedures the policy requires, held current

• Policy approved once at programme launch and never reviewed
• Response teams have never seen the policy that names them
• Procedures referenced by the policy do not exist

Analyse the impact of plausible disruptions and the risks behind them, and use the results to set the criteria continuity and resilience strategies must satisfy.

• The business impact analysis with recovery time and recovery point objectives per process
• The risk assessment feeding the analysis
• Evidence the analysis is current against the present business
• The criteria derived from it that strategies are judged against

• Impact analysis older than the business it describes
• Recovery objectives asserted without analysis behind them
• Analysis performed but strategy chosen without reference to it

Choose continuity strategies that bring the effect of a disruption inside the stated risk appetite, covering how the organisation will absorb, withstand and recover from the event.

• Documented continuity strategies with the option analysis behind each
• The stated risk appetite the strategies were tested against
• Approval of the chosen strategies by an accountable authority
• Evidence the strategy meets the recovery objectives from the impact analysis

• Strategy that cannot in fact meet the stated recovery objectives
• Risk appetite never stated, so nothing anchors the choice
• Strategy chosen on cost alone with no resilience analysis

Write a business continuity plan that implements the chosen resilience strategies, and keep it approved, communicated and maintained.

• The current business continuity plan with version and approval
• Traceability from the plan back to the chosen strategies
• Distribution records showing plan holders have the current version
• Maintenance record showing the plan was updated after change

• Plan holders carrying superseded versions
• Plan contents not traceable to any strategy or impact analysis
• Plan lists contacts and systems that no longer exist

Produce and hold the documentation the continuity and resilience programme depends on, make it reachable by the people authorised to use it, and review it on a set cycle.

• The documentation set the programme depends on, with owners
• Access arrangements proving authorised responders can reach it during an outage
• Review records against the defined cycle
• Evidence of offline or alternate-site availability

• Continuity documentation stored only on the system it is meant to recover
• Review cycle defined but not performed
• No record of who is authorised to access it

Run a live exercise of the continuity and resilience plans every year, repeat it whenever something significant changes, and feed what the exercise exposes back into the plans.

• Exercise plans and reports from the last twelve months
• Scenario and scope covered by each exercise
• Post-exercise findings with owners and closure evidence
• Records of exercises triggered by significant change

• Walkthrough discussions recorded as exercises without anything being tested
• Findings raised at each exercise and never closed before the next
• No exercise after a major architecture or supplier change

Set out how stakeholders and participants will be contacted and kept informed while continuity and resilience procedures are running.

• The continuity communication plan with audiences, channels and triggers
• Current contact lists for internal and external stakeholders
• Evidence contact details are verified on a cycle
• Communication records or templates used in an exercise or real event

• Contact lists stale, with people who have left still listed as responders
• Single communication channel that fails with the primary systems
• Customer and regulator communication not covered, only internal

Back up cloud-held data on a defined cycle, protect the confidentiality and integrity of the backups, and prove by restore testing that the data can actually be recovered.

• Backup schedules and job success records
• Backup encryption and access control configuration
• Restore test results with date, scope and outcome
• Retention settings matched to the recovery point objective

• Backups running successfully but never restore tested
• Backups readable by the same credentials that could destroy production
• Restore tested for one system and the result generalised to all

Maintain an approved disaster response plan covering natural and man-made events, and update it at least annually or when something significant changes.

• The approved disaster response plan with its version and date
• Coverage of both natural and man-made scenarios
• Annual update record and change-triggered updates
• Named response roles with deputies

• Plan covers technology failure only and ignores physical and human-caused events
• Named responders no longer in post
• Update triggered by nothing, so the plan drifts from reality

Rehearse the disaster response plan every year and after significant change, involving local emergency authorities where that is possible.

• Rehearsal records for the last twelve months
• Evidence of engagement with local emergency authorities or the reason it was not possible
• Findings from the rehearsal and their closure
• Participation list showing the named response roles took part

• Rehearsal run by the continuity team alone with no operational participants
• External authority engagement never attempted or documented
• Findings not fed back into the plan

Provide redundant units of business-critical equipment, sited far enough apart that one local event cannot take out both, using the separation industry standards call for.

• The inventory of business-critical equipment and its redundant counterparts
• Site or location records showing the separation distance
• The industry standard the separation was set against
• Evidence redundancy has been failed over to or tested

• Redundant equipment in the same room or same power and cooling domain
• Redundancy assumed from a supplier claim and never tested
• No definition of which equipment is business-critical

Keep approved change management policies and procedures covering the risk of changing applications, systems, infrastructure and configuration, whether the asset is run in-house or by a supplier, and review them at least annually.

• The approved change management policy with scope covering outsourced assets
• Annual review record
• Procedures for standard, normal and emergency change
• Evidence the policy was communicated to internal teams and suppliers

• Policy scope silent on supplier-managed assets, leaving them ungoverned
• Emergency change path undefined so it becomes the default route
• Annual review missed

Put changes through a defined quality control path with approval, established baselines, testing and release standards before they reach production.

• The documented change approval and testing process
• Test results attached to recent production changes
• Release standards and the baseline each change was tested against
• Approval records showing an authority separate from the implementer

• Changes approved by the person who wrote them
• Test evidence not retained with the change record
• Release standards defined but unenforced for urgent work

Actively manage the risk each change introduces to applications, systems, infrastructure and configuration, including assets operated by outsourced providers.

• Risk assessment recorded against individual changes
• Evidence outsourced provider changes are captured and assessed
• Criteria that decide when a change needs deeper assessment
• Records of changes rejected or reworked on risk grounds

• Risk field on the change record filled in as low by default
• Supplier changes arriving with no notice and no assessment
• No criteria, so risk rating is arbitrary between assessors

Prevent assets from being added, removed, updated or administered by anyone who has not been authorised to do so.

• Technical controls restricting who may change assets, such as pipeline permissions and console roles
• The authorised changer list and how it is kept current
• Detection records for unauthorised change attempts
• Evidence of enforcement in production, not only in policy

• Broad standing administrative rights that make the restriction notional
• Restriction enforced in the pipeline but bypassable through direct console access
• No detection, so an unauthorised change would not be noticed

Write into customer service agreements that changes touching a customer's own environment or tenant will only be made in response to explicitly authorised requests.

• Service agreement clauses covering customer-impacting change authorisation
• Records of customer authorisation for changes made to their tenant
• The process that enforces the clause operationally
• Exception records where a change was made without prior authorisation

• Clause present in the contract with no operational process behind it
• Provider-initiated maintenance treated as outside the clause
• Authorisation captured informally and not retained

Record a configuration baseline for every authorised change, so the approved state of each asset is known.

• Baseline definitions per asset class and the tool holding them
• Baseline updated as part of the change record for recent changes
• Coverage report showing which assets have a baseline
• Ownership of each baseline

• Baselines held for servers only, with network and cloud configuration excluded
• Baseline not updated when the change lands, so it immediately reads as drift
• No coverage measure, so gaps are invisible

Detect drift away from the approved configuration baseline and raise a proactive notification to the responsible party rather than waiting for the next review.

• Drift detection tooling configuration and the assets it covers
• Sample alerts raised and the response to them
• Notification routing showing who receives a drift alert
• Time from drift to notification

• Detection runs but alerts go to an unmonitored mailbox
• Coverage limited to a subset of assets while the baseline claims all
• Alerts suppressed because the noise level was never tuned

Handle exceptions and emergency changes through a defined procedure aligned with the organisation's policy exception process.

• The documented exception and emergency change procedure
• Exception records with approver, justification and expiry
• Evidence of alignment with the governance policy exception process
• Retrospective review records for emergency changes

• Emergency changes never reviewed after the fact
• Exceptions granted without an expiry date
• Two separate exception processes that do not agree with each other

Be able to roll a change back to the last known good state when it produces errors or a security concern, through a defined and tested process.

• The documented rollback process
• Rollback plans attached to recent significant changes
• Evidence a rollback has been performed or tested
• Definition of what constitutes the known good state per asset

• Rollback plan written as a single line saying restore from backup
• Rollback never tested, so its feasibility is unknown
• No defined known good state, so there is nothing to roll back to

Keep approved cryptography, encryption and key management policies and procedures, communicate them to the teams that operate cryptography, and review them at least annually.

• The approved cryptography and key management policy with approver and date
• Annual review record
• Evidence of communication to engineering and operations teams
• The approved algorithm and key length standard the policy references

• Policy naming algorithms that are now deprecated
• Annual review missed
• Key management procedures held by one engineer and not documented

Name who is accountable for each part of cryptography, encryption and key management, and put those responsibilities into practice.

• A responsibility matrix covering key generation, custody, rotation, revocation and destruction
• Named individuals or roles against each responsibility
• Evidence the named holders perform the duty, such as signed key ceremony records
• Backup or deputy assignments

• Responsibilities assigned to a team name with no individual accountable
• Key custodian left the organisation and was never replaced
• Matrix documented but the work is actually done by someone else

Apply cryptographic protection to stored data and to data moving across networks, using libraries that hold certification against an approved standard.

• Configuration evidence showing encryption enabled at rest and in transit per system
• The certification of the cryptographic libraries or modules in use, such as a validation certificate
• Inventory of data stores and transport paths with their encryption status
• Exceptions where encryption is not applied and the risk acceptance behind them

• Encryption at rest claimed from a provider default without verification per data store
• Uncertified or self-built cryptographic implementations in use
• Internal traffic left unencrypted because it is considered a trusted network

Select encryption algorithms that suit the classification of the data, the risk it carries and the practical usability of the technology, rather than applying one algorithm everywhere.

• The approved algorithm standard mapped to data classification levels
• The rationale recorded for each selection
• Evidence systems use the algorithm their data classification requires
• Review record showing the selection was revisited as cryptographic guidance changed

• A single algorithm applied to all data regardless of classification
• Legacy algorithms retained for compatibility with no documented risk acceptance
• Selection never revisited as published guidance moved on

Route changes to cryptographic, encryption and key management technology through a standard change procedure covering review, approval, implementation and communication, whether the change originates inside or outside the organisation.

• The change procedure covering cryptographic technology specifically
• Change records for recent cryptographic changes with approvals
• Evidence externally driven changes, such as a vendor deprecation, entered the same process
• Communication records to affected parties

• Cryptographic library upgrades treated as routine patching outside change control
• Vendor-driven changes accepted with no internal review
• Affected downstream consumers not told before the change lands

Assess the downstream effect of any proposed cryptography or key management change, including residual risk, cost and benefit, before adopting it.

• Impact analyses for recent cryptographic changes
• Residual risk statement and cost benefit reasoning per change
• Identification of dependent systems and data affected
• Approval that references the analysis

• Analysis limited to the changed component with dependents unexamined
• Cost considered and residual risk omitted
• Analysis produced after the decision was already taken

Run a risk programme specific to encryption and key management covering risk context, assessment, treatment, monitoring and feedback.

• The encryption and key management risk register
• Documented risk context and assessment method
• Treatment plans with owners for open cryptographic risks
• Monitoring and feedback records showing the register is live

• Cryptographic risks folded into a general register where they lose visibility
• Register populated once and never revisited
• Treatments assigned with no owner or date

Give cloud customers the means to manage the encryption keys that protect their own data.

• Documentation of the customer key management capability offered
• Technical evidence the capability works, such as a customer-managed key configuration
• Guidance published to customers on how to use it
• Records of customers who have taken it up

• Capability described in marketing material but not available in the product
• Customer keys held in a way the provider can still unilaterally use
• No documentation, so customers cannot exercise the capability

Subject the key management platform, together with its governing policy and process, to audit at a frequency proportionate to its risk exposure, no less than yearly and again after any security event.

• Audit reports covering key management systems from the last twelve months
• The frequency decision and the risk exposure it was based on
• Evidence of an audit triggered by a security event
• Findings and their remediation

• Annual audit scoped to policy documents without examining the key management system itself
• No audit after a security event that touched cryptographic material
• Frequency set by convenience rather than risk

Generate keys only through accepted cryptographic libraries, and record for each key the strength selected and the source of randomness it was produced from.

• Key generation procedure naming the library, algorithm strength and entropy source
• Key ceremony or generation records for recent keys
• Evidence of the random number generator in use and its suitability
• The library version and its accepted status

• Entropy source undocumented, so key quality cannot be assessed
• Keys generated on developer workstations outside the defined procedure
• Algorithm strength recorded for new keys but unknown for legacy ones

Provision each secret and private key for a single defined purpose and manage it accordingly.

• Key inventory showing the declared purpose of each key
• Evidence keys are not reused across purposes or environments
• Provisioning records tying a key to its purpose at creation
• Detection or review that catches purpose reuse

• One key shared across signing and encryption
• Production and non-production sharing keys
• Purpose recorded at creation but never checked afterwards

Rotate keys on the cryptoperiod calculated for them, accounting for the risk of information disclosure and any legal or regulatory requirement.

• The cryptoperiod calculated per key type and the reasoning behind it
• Rotation records showing keys rotated on schedule
• Alerting or automation that triggers rotation
• Legal or regulatory requirements that constrain the cryptoperiod

• Rotation schedule defined but manual and routinely missed
• Cryptoperiod set to a round number with no analysis
• Keys embedded in systems that cannot rotate without an outage, so they never do

Revoke and remove keys before the end of their cryptoperiod when a key is compromised or the holder leaves the organisation, through a defined and evaluated process.

• The revocation procedure with trigger conditions
• Revocation records tied to compromise events and leaver events
• Evidence revocation is linked to the joiner mover leaver process
• Verification that a revoked key no longer works

• Leaver process does not trigger key revocation
• Revocation recorded but the key remains usable in some systems
• No verification step, so revocation is assumed rather than proven

Destroy keys held outside a secure environment and revoke keys held in hardware security modules once they are no longer needed, through a defined and evaluated process.

• The key destruction and revocation procedure distinguishing HSM-held from externally held keys
• Destruction records with method, date and witness
• HSM revocation records
• Evidence of periodic review identifying keys no longer needed

• Keys marked obsolete but never actually destroyed
• Destruction unwitnessed and unrecorded
• Copies of keys in backups outlive the destruction event

Create keys in a pre-activated state so a generated key cannot be used until it has been explicitly authorised for use.

• The procedure describing the pre-activated state and the authorisation step
• System configuration showing keys default to inactive on generation
• Authorisation records moving keys into active use
• Evidence a key cannot be used while pre-activated

• Keys immediately active on generation with no authorisation gate
• Pre-activation state exists in the procedure but not in the system
• Authorisation performed by the same person who generated the key

Monitor, review and approve every transition of a key into or out of suspension, so no key changes state unnoticed.

• The suspension procedure with approval requirements
• Records of suspension and reinstatement events with approver
• Monitoring or alerting on key state changes
• Review evidence for suspended keys still in that state

• Suspension performed operationally with no approval trail
• Keys left suspended indefinitely with no review
• State changes not monitored, so an unauthorised reinstatement would pass unseen

Deactivate each key at its expiry date through a defined and evaluated process rather than leaving expired keys usable.

• The deactivation procedure and its trigger on expiry date
• Key inventory showing expiry dates and current state
• Deactivation records for keys that have passed expiry
• Evidence an expired key is technically unusable

• Expiry dates recorded but nothing acts on them
• Expired keys still accepted by systems for compatibility
• Deactivation done manually and inconsistently across key stores

Hold archived keys in a secure repository that grants access on a least privilege basis.

• The archive repository and its security configuration
• Access control list for the archive with justification per holder
• Access logs for the archive
• Procedure covering when and how a key is retrieved from archive

• Archive access granted to the whole cryptography team by default
• Archive held in general file storage rather than a controlled repository
• No access logging, so retrieval cannot be reviewed

Restrict a compromised key so that after compromise it is used only to decrypt existing data under controlled circumstances, and never to encrypt anything new.

• The compromised key handling procedure stating the decrypt-only restriction
• Records of compromised keys and the restriction applied
• Technical evidence the key cannot be used for encryption
• The controlled circumstances under which decryption is permitted, and who authorises it

• Compromised key left fully usable while re-encryption is planned
• Restriction stated in procedure with no technical enforcement
• No record of which data still depends on the compromised key

Weigh the risk of losing control of keying material against the risk to operational continuity if a key cannot be recovered, and set recovery arrangements on that basis.

• The documented analysis comparing exposure risk against continuity risk
• Key recovery or escrow arrangements and their access controls
• The decision record showing which keys are recoverable and which are not
• Test evidence that recovery works where it is provided

• Escrow implemented for convenience with no risk analysis behind it
• No recovery arrangement for keys whose loss would be unrecoverable for the business
• Recovery arrangement never tested

Have the key management system track every item of cryptographic material and report each change in its status.

• The key inventory produced by the key management system
• Status change reporting output
• Coverage evidence showing all key stores feed the inventory
• Reconciliation between the inventory and keys actually present in systems

• Inventory covers the central key store while application-held keys are invisible
• Status changes not reported, only current state shown
• Inventory maintained by hand in a spreadsheet and out of date

Keep approved procedures for securely disposing of equipment used away from company premises, and where equipment is not physically destroyed, apply a data destruction method that makes recovery impossible. Review at least annually.

• The approved off-site equipment disposal procedure
• Annual review record
• Destruction certificates or sanitisation records for disposed equipment
• The sanitisation standard applied where equipment was not destroyed

• Disposal handled by a third party with no certificate returned
• Sanitisation method chosen that leaves data recoverable
• Procedure covers datacentre equipment only and omits equipment used off premises

Require written or cryptographically verifiable authorisation before hardware, software or data is relocated or transferred to an offsite or alternate location, under policies reviewed at least annually.

• The relocation and transfer procedure stating the authorisation requirement
• Authorisation records for recent transfers
• Evidence the authorisation is written or cryptographically verifiable
• Annual review record

• Transfers approved verbally with no retained record
• Authorisation retained but not attributable to a specific approver
• Data transfers treated as out of scope, with only hardware covered

Maintain approved procedures for keeping offices, rooms and facilities a safe and secure working environment, and review them at least annually.

• The secure area procedure with approver and date
• Annual review record
• Evidence of application, such as area designations and their controls
• Communication to staff working in those areas

• Procedure covers the datacentre and omits offices where data is handled
• Annual review missed
• Designations exist on paper with no matching physical control

Maintain approved procedures for transporting physical media securely between locations, and review them at least annually.

• The secure media transport procedure
• Transport records for recent media movements including carrier and chain of custody
• Encryption or protection applied to media in transit
• Annual review record

• Media transported by general courier with no chain of custody
• Unencrypted media relied on physical control alone
• No log of what media moved where

Classify physical and logical assets by the business risk they carry, and record the classification.

• The asset classification scheme and its risk criteria
• Asset records carrying a classification value
• Coverage evidence across both physical and logical assets
• Review record showing classifications are revisited

• Logical assets such as applications left unclassified while hardware is covered
• Classification assigned at onboarding and never revisited
• Scheme has levels but no criteria, so assignment is inconsistent

Hold every relevant physical and logical asset across all provider sites in a catalogue kept inside a secured tracking system.

• The asset catalogue and the system holding it
• Access controls on the catalogue itself
• Coverage evidence across all sites
• Reconciliation between the catalogue and a physical or discovery check

• Catalogue held in an open spreadsheet rather than a secured system
• One site maintained diligently and others omitted
• No reconciliation, so the catalogue drifts from reality

Build physical security perimeters around people, data and systems, including a perimeter separating administrative and business areas from data storage and processing areas.

• Site plans showing defined perimeters and the internal separation
• Physical controls implementing each perimeter
• Evidence the administrative to data area boundary is enforced
• Assessment of perimeter effectiveness

• Single perimeter at the building edge with no internal separation
• Doors between zones held open for convenience
• Perimeter defined in documentation and absent in the building

Authenticate connections using equipment identity, so a device must be recognised before it is allowed to connect.

• Configuration showing device authentication, such as certificate based network access control
• The device identity register
• Records of connection attempts refused for unrecognised equipment
• Coverage across the network segments where it is required

• Device authentication enabled on one segment and absent elsewhere
• Fallback to open access when device authentication fails
• Device identity register not maintained, so stale devices remain trusted

Admit only authorised people to secure areas, restrict and monitor every entry and exit point with physical access mechanisms, and retain the access records for the period the organisation has set.

• The authorised access list per secure area and its review records
• Physical access control configuration covering ingress and egress
• Access logs retained for the defined period
• Records of access reviews and removals

• Egress not controlled or monitored, only entry
• Access list never reviewed, so leavers retain badge rights
• Retention period undefined, so logs are purged inconsistently

Operate surveillance across the datacentre outer perimeter and every entry and exit point to detect attempts at unauthorised entry or exit.

• Camera coverage plan against the perimeter and all access points
• Recording retention and its configuration
• Evidence surveillance is monitored or alerts are acted on
• Maintenance records showing the system is operational

• Blind spots at access points that the coverage plan does not acknowledge
• Cameras recording with nobody reviewing and no alerting
• Failed cameras unnoticed because there is no health check

Train datacentre personnel on how to respond when someone attempts unauthorised entry or exit.

• The training material covering unauthorised access response
• Attendance records for datacentre personnel
• Frequency of refresher training
• Evidence of a drill or scenario exercise

• Training given at induction only with no refresher
• Contract security staff excluded from the training
• No drill, so the response has never been practised

Protect power and telecommunications cabling at every facility, office and room against interception, interference and damage, sized to the assessed risk.

• The cabling risk assessment
• Protective measures in place such as conduit, segregation or locked cable rooms
• Coverage across facilities, offices and rooms
• Inspection records

• Datacentre cabling protected while office cabling is exposed
• Power and data cabling run together with no segregation
• No inspection, so damage or tampering would not be found

Run environmental controls in the datacentre that hold temperature and humidity within industry accepted ranges, and test their effectiveness on a continuing basis.

• Environmental monitoring records for temperature and humidity
• The accepted range applied and the standard it comes from
• Alerting configuration for out-of-range conditions
• Maintenance and effectiveness test records

• Monitoring in place with no alert thresholds set
• Ranges chosen locally with no reference to an industry standard
• Environmental systems maintained but never tested under load

Secure, monitor, maintain and test utility services at planned intervals so continued supply is proven rather than assumed.

• The utilities inventory covering power, cooling and telecommunications
• Monitoring and alerting configuration
• Maintenance schedule and completed maintenance records
• Test records such as generator load tests and their results

• Generators maintained but never load tested
• Fuel or supply contracts not verified against the required runtime
• Utility monitoring absent, so a partial failure is discovered late

Site business-critical equipment away from locations with a high likelihood of environmental hazard.

• The environmental hazard assessment for each site
• Equipment placement records against the assessment
• Mitigations where equipment must sit in a higher risk location
• Review of siting decisions after any hazard event

• Critical equipment in basements or beneath water services with no mitigation
• Hazard assessment done at build and never revisited
• Placement decided by available space rather than risk

Keep approved policies for classifying, protecting and handling data across its whole lifecycle in line with applicable law, standards and assessed risk, and review them at least annually.

• The approved data security and privacy policy with approver and date
• Annual review record
• The lifecycle stages the policy covers, from creation to destruction
• Evidence of communication to data handling staff

• Policy covers storage and omits collection, transfer or destruction
• Annual review missed
• Applicable law identified once and not tracked as it changed

Dispose of data on storage media using industry accepted methods that leave it unrecoverable by forensic means.

• The disposal standard and sanitisation method applied per media type
• Disposal or destruction records with dates
• Certificates from any third party performing destruction
• Verification that the method used defeats forensic recovery

• Deletion at the file system level treated as secure disposal
• Cloud storage disposal assumed from the provider with no evidence
• No record linking disposed media to the data it held

Maintain an inventory of data holdings covering at least all sensitive and personal data.

• The data inventory with sensitive and personal data identified
• The method by which new data holdings enter the inventory
• Coverage evidence across systems and environments
• Review records keeping the inventory current

• Inventory built once by survey and never maintained
• Shadow systems and exports not represented
• Personal data held in unstructured stores omitted entirely

Assign each dataset a classification reflecting its type and sensitivity.

• The classification scheme with defined levels and criteria
• Classification values recorded against datasets
• Evidence classification drives handling, such as differing controls by level
• Review records for reclassification

• Scheme published but most data left unclassified
• Classification assigned without any control difference between levels
• Datasets classified at creation and never reassessed when their content changed

Document where data is processed, stored and transmitted, and refresh that mapping on a set schedule, yearly at the outside, and whenever something changes.

• Current data flow documentation showing processing, storage and transmission points
• Review records against the defined interval
• Evidence of update after a system or supplier change
• Coverage across the systems handling sensitive and personal data

• Data flow diagrams drawn for an audit and not maintained afterwards
• Third party and sub-processor flows omitted
• No change trigger, so the map silently diverges from the architecture

Record who owns and who stewards each set of personal and sensitive data, and review those assignments at least annually.

• The ownership and stewardship register naming individuals or roles
• Annual review record of the assignments
• Evidence owners exercise their duty, such as approving access
• Handover records when an owner changes

• Ownership assigned to a department rather than an accountable person
• Owners who have left still recorded
• Owners unaware they hold the role

Design security into systems, products and business practices from the outset rather than adding it afterwards, following recognised practice.

• Design documentation showing security requirements set at the design stage
• Design review or architecture review records
• The recognised practice or standard being followed
• Evidence the approach applies to business practices, not only technology

• Security review inserted just before release and treated as design input
• Approach applied to new build only, with change to existing systems exempt
• No standard named, so security by design means whatever the reviewer thinks

Design privacy into systems, products and business practices, and ship them with privacy settings enabled by default as applicable law requires.

• Design records showing privacy requirements considered at design stage
• Evidence of default privacy settings in the shipped configuration
• The legal requirements the defaults were set against
• Review of defaults after a product change

• Privacy settings available but defaulted to the least protective option
• Privacy considered only where a regulator is expected to look
• Defaults set at launch and never rechecked as the product changed

Assess the privacy impact of personal data processing, examining where the risk comes from, what kind of risk it is, how specific it is to this processing and how severe it could be, wherever law or good practice calls for such an assessment.

• Completed data protection impact assessments for relevant processing
• The trigger criteria that decide when an assessment is required
• Risk treatment arising from each assessment
• Sign-off by the accountable privacy authority

• Trigger criteria undefined, so assessments are done ad hoc
• Assessment completed after processing began
• Risks identified in the assessment with no treatment recorded

Protect personal and sensitive data whenever it is transferred, and confine the processing to purposes the relevant laws and regulations permit.

• Technical protections applied to transfers, such as encryption in transit and endpoint authentication
• The legal basis and permitted scope for each category of transfer
• Records of transfers including cross-border ones
• Evaluation evidence that the measures work as intended

• Transfer protections applied to external transfers while internal ones are unprotected
• Cross-border transfer legal basis not recorded
• Scope permitted by law not translated into any technical restriction

Give data subjects a working route to request access to, correction of or deletion of their personal data, and fulfil those requests as applicable law requires.

• The published request route and the procedure behind it
• A log of requests received with dates and outcomes
• Evidence requests were fulfilled inside the legal timeframe
• The technical means by which data is located, changed or deleted across systems

• Request route published with no process behind it
• Deletion performed in the primary system while backups and exports retain the data
• Timeframes missed with no record of why

Confine personal data processing to the purposes declared to the data subject and permitted by applicable law, and be able to demonstrate that limit.

• The declared purposes per processing activity and the notice given to data subjects
• Controls that prevent processing outside the declared purpose
• Evaluation evidence such as a review of actual processing against declared purpose
• Records of new purposes and how consent or legal basis was re-established

• Data collected for one purpose reused for analytics without re-establishing a basis
• Declared purposes written so broadly they permit anything
• No review comparing actual processing to declared purpose

Control how personal data is passed to and processed by sub-processors in the service supply chain, in line with applicable law.

• The sub-processor register with the data each one handles
• Contractual terms binding sub-processors to the required protections
• Due diligence records before engagement
• Evaluation or audit of sub-processor practice

• Sub-processors engaged by delivery teams without the register being updated
• Contracts silent on data protection obligations
• Due diligence at onboarding with no ongoing evaluation

Tell the data owner which sub-processors will access their personal or sensitive data before that processing starts.

• The notification procedure and its timing relative to processing
• Notification records sent to data owners
• The detail disclosed, such as sub-processor identity, location and purpose
• Evidence of notification when a sub-processor changed

• Notification given after processing has already begun
• Sub-processor list published on a web page with no active notification
• Changes to the sub-processor set not notified

Obtain the data owner's authorisation and treat the resulting risk before production data is copied into or used in a non-production environment.

• Authorisation records from data owners for production data use in non-production
• The risk assessment and treatment applied, such as masking or subsetting
• Controls on non-production environments holding such data
• Records of removal once the need ended

• Production data copied to test environments as routine practice with no authorisation
• Masking applied inconsistently so some fields remain live
• Copies left in non-production indefinitely

Manage data retention, archiving and deletion against business requirements and applicable law, so data is neither kept longer nor destroyed sooner than allowed.

• The retention schedule by data type with the requirement behind each period
• Evidence retention periods are enforced technically
• Deletion records at end of retention
• Legal hold procedure and its interaction with deletion

• Retention schedule published with no technical enforcement
• Data retained indefinitely because deletion was never built
• Legal hold not accounted for, so data under hold is deleted

Apply protective measures to sensitive data at every stage of its lifecycle, from creation through to destruction.

• The lifecycle stages identified and the protection applied at each
• Technical measures such as encryption, tokenisation or access restriction per stage
• Evaluation evidence that the measures operate
• Coverage across systems holding sensitive data

• Protection concentrated at rest with data in use or in transit unprotected
• Sensitive data in logs, caches or exports left out of scope
• Measures deployed but never evaluated for effectiveness

Have a documented procedure for handling law enforcement demands for personal data, describe it to cloud customers, and notify affected customers unless notification is legally prohibited.

• The law enforcement request handling procedure
• The description provided to customers
• A log of requests received, the legal review applied and the outcome
• Notification records or the legal basis for withholding notification

• Procedure exists internally but was never described to customers
• Requests handled by whoever received them with no legal review
• Notification withheld as a default rather than on a legal basis

Record the physical locations where data is held, processed and backed up, and be able to produce that record.

• The data location record covering processing, storage and backup sites
• The method that keeps it current as infrastructure changes
• Evidence it is available to customers or regulators who may ask
• Coverage of sub-processor locations

• Locations recorded for primary storage with backup and replica locations omitted
• Record based on contracted regions rather than actual deployment
• Sub-processor locations unknown

Keep approved information governance policies and procedures with visible sponsorship from organisational leadership, and review them at least annually.

• The approved governance policy showing leadership sponsorship
• Evidence of leadership engagement such as steering committee minutes
• Annual review record
• Communication of the policy across the organisation

• Sponsorship claimed in the policy with no leadership activity behind it
• Annual review missed
• Governance programme run entirely below leadership visibility

Run a documented enterprise risk management programme, sponsored by leadership, that identifies, evaluates, assigns ownership of, treats and accepts cloud security and privacy risks.

• The enterprise risk management policy and procedure
• The risk register showing cloud security and privacy risks
• Risk owners named and treatment plans recorded
• Formal risk acceptance records with the accepting authority

• Cloud risks absent from an otherwise functioning enterprise register
• Risks accepted informally with no named accepting authority
• Treatment plans with no owner or completion date

Review every relevant organisational policy and its supporting procedures at least annually and whenever the organisation changes substantially.

• A policy register with last review and next review dates
• Review records for the current cycle
• Evidence of review triggered by substantial organisational change
• The definition of what counts as a substantial change

• Some policies reviewed and others silently overdue
• Reviews recorded as complete with no change or comment, suggesting no real review
• No change trigger defined, so reviews are calendar driven only

Handle any deviation from an established policy through an approved exception process defined by the governance programme.

• The documented policy exception process
• Exception records with justification, compensating control, approver and expiry
• A register of open exceptions
• Evidence expired exceptions are closed or renewed deliberately

• Exceptions granted with no expiry, becoming permanent by default
• Compensating controls not stated, so the residual risk is unmanaged
• Deviations occurring with no exception raised at all

Operate an information security programme that covers all the domains of the control framework rather than a chosen subset.

• The information security programme description and its domain coverage
• A coverage map from programme components to framework domains
• Programme governance records such as reporting and reviews
• Resourcing and ownership per domain

• Programme strong on technical domains and absent on supply chain or privacy
• Coverage asserted with no map, so gaps are invisible
• Domains named with nobody accountable for them

Document who plans, implements, operates, assesses and improves the governance programme, and what each of those roles is accountable for.

• A responsibility model covering plan, implement, operate, assess and improve
• Named roles or individuals against each
• Evidence the assessment role is independent of the operate role
• Review of the model as the organisation changes

• Assessment and operation held by the same role, removing independence
• Model documented at a level too abstract to hold anyone accountable
• Improvement stage unassigned, so findings never drive change

Identify and record every standard, regulation, contractual and statutory requirement that applies to the organisation.

• The regulatory and contractual obligations register
• The method by which new obligations are detected and added
• Owner assigned per obligation
• Evidence the register is reconciled against actual operations and jurisdictions

• Register covers regulation and omits contractual security commitments
• New jurisdictions entered without the register being updated
• Obligations listed with no owner, so none is actively tracked

Take part in cloud-focused industry groups and comparable external bodies chosen to suit the business, and keep that participation live rather than nominal.

• The list of groups and bodies the organisation participates in
• Membership or participation evidence
• Records of intelligence or guidance received and how it was used
• The rationale for which groups are relevant to the business

• Memberships held with no participation and no information flowing in
• Intelligence received but never routed to anyone who acts on it
• Group selection unrelated to the organisation's actual risk profile

Keep approved background verification procedures for all new employees, contractors and third parties, scaled to the data they will access, the business requirement and accepted risk, and consistent with local law. Review at least annually.

• The background screening procedure with the scaling criteria
• Screening records for recent hires, contractors and third party staff
• Evidence of legal constraints considered per jurisdiction
• Annual review record

• Contractors and third party staff excluded from screening
• One screening depth applied regardless of data access
• Screening completed after access was granted

Define in policy what use of organisation-owned or managed assets is acceptable and under what conditions, and review that policy at least annually.

• The acceptable use policy with approver and date
• Acknowledgement records from staff
• Annual review record
• The conditions and allowances the policy sets out

• Policy signed at induction with no re-acknowledgement after material change
• Personally owned devices used for work with no policy position
• Annual review missed

Require that unattended workspaces carry no openly visible confidential information, through an approved policy reviewed at least annually.

• The clear desk policy with approver and date
• Evidence of enforcement such as walkthrough or sweep records
• Annual review record
• Communication and acknowledgement by staff

• Policy exists with no check that it is followed
• Sweeps performed in the office only while home workspaces are unaddressed
• Findings from sweeps not followed up

Maintain approved procedures protecting information accessed, processed or stored away from company premises, and review them at least annually.

• The remote and home working procedure
• Technical controls supporting it, such as device encryption and secure connectivity
• Annual review record
• Evidence the procedure reached remote staff

• Procedure written for occasional remote work and never updated for sustained remote working
• Home network and physical environment risks unaddressed
• Controls stated in procedure with no technical enforcement

Document how organisation-owned assets are recovered from employees when their employment ends.

• The asset return procedure within the leaver process
• Asset return records matched to recent leavers
• The asset register used to determine what each leaver holds
• Escalation path for assets not returned

• Return process depends on the leaver remembering what they hold
• No reconciliation against the asset register
• Unreturned assets recorded and then not pursued

Set out and communicate to all personnel the roles and responsibilities that apply when someone's employment changes or ends.

• The employment change and termination procedure with responsibilities named
• Evidence it was communicated to all personnel
• Records of the procedure applied to recent changes and leavers
• Coordination points between HR, IT and security

• Procedure known to HR only and not to the managers who must act
• Role change treated as no event, leaving accumulated access in place
• Communication assumed from the handbook with no confirmation

Have employees sign their employment agreement before any access to organisational systems, resources or assets is granted.

• Signed employment agreements with dates
• Access provisioning records with dates, to compare against signature dates
• The control that prevents provisioning before signature
• Exception records where access preceded signature

• Access granted on start date with the agreement signed later
• No comparison between signature and provisioning dates
• Contractors given access under no agreement at all

Write adherence to information governance and security policy into the terms of the employment agreement.

• The employment agreement template showing the security and governance terms
• Evidence current staff are on a version carrying those terms
• The policies the terms bind staff to
• Review of the terms as policy changes

• Terms present in the current template while long-serving staff remain on older versions
• Terms reference policies that no longer exist
• Contractor agreements omit the terms entirely

Document and communicate what each employee is responsible for in relation to information assets and their security.

• Role descriptions or a responsibility statement covering information security duties
• Evidence of communication to each employee
• Differentiation of duties by role where that is warranted
• Acknowledgement records

• One generic statement issued to everyone regardless of role
• Communication at induction only
• Responsibilities documented in policy but absent from role descriptions

Identify and review at planned intervals the confidentiality and non-disclosure terms the organisation needs to protect its data and operational detail.

• The non-disclosure agreement templates in use
• The requirements analysis behind the terms
• Review records against the planned interval
• Coverage across employees, contractors and third parties

• Templates in use with no record of what they are meant to protect
• Review interval defined and not observed
• Third parties engaged with no confidentiality terms

Run a security awareness training programme for all employees and refresh the training on a regular cycle.

• The training programme content and its approval
• Completion records covering all employees
• The refresh cycle and evidence it is met
• Follow-up for non-completers

• Completion below full coverage with no follow-up
• Content unchanged year on year so it stops being read
• Contractors and temporary staff excluded

Give employees who handle sensitive organisational or personal data awareness training tuned to their function, and update it as procedures and policies change.

• Role-specific training content for staff handling sensitive and personal data
• Identification of which staff fall into that population
• Completion records for that population
• Evidence content was updated when procedures or policies changed

• Same general awareness training given to sensitive data handlers as to everyone else
• The population of sensitive data handlers not identified
• Content not updated after a significant policy change

Make employees aware that they are personally responsible for following policy and for meeting the legal, statutory and regulatory obligations attaching to their work.

• Communications making individual responsibility explicit
• Acknowledgement records
• The specific obligations communicated to each relevant group
• Evidence of reinforcement beyond induction

• Responsibility implied by policy but never stated to the individual
• Legal obligations described generically with no link to the person's actual work
• Acknowledgement captured once at induction and never again

Keep approved identity and access management policies and procedures, put them into effect, and review them at least annually.

• The approved identity and access management policy with approver and date
• Annual review record
• The procedures implementing it, such as provisioning and review procedures
• Evidence of communication to the teams that grant access

• Policy written and never implemented in the systems it governs
• Annual review missed
• Procedures exist for the main directory only, leaving cloud and application identity ungoverned

Keep an approved password policy that sets strength requirements, implement it in the systems it governs, and review it at least annually.

• The approved password policy with its strength requirements
• Technical configuration enforcing the policy per system
• Annual review record
• Exception records where a system cannot enforce the policy

• Policy strength requirements not enforceable in some systems and no exception recorded
• Policy stated in words with no configuration evidence
• Requirements based on outdated guidance such as frequent forced rotation without other controls

Hold a record of every system identity and the access level it carries, and review that record.

• The identity inventory covering human and non-human identities
• The access level recorded against each
• Review records for the inventory
• Coverage across directories, cloud platforms and applications

• Service accounts and machine identities missing from the inventory
• Access level recorded at creation and not maintained
• Inventory limited to the central directory

Split duties across separate identities so no single person can both perform and approve a sensitive action.

• The documented separation of duties matrix for sensitive actions
• Technical enforcement, such as approval workflows that exclude the requester
• Evidence of conflicts detected and resolved
• Review records for the matrix

• Separation defined on paper with the system permitting self-approval
• Break glass accounts that defeat separation with no compensating monitoring
• Matrix never reviewed as roles changed

Grant each identity only the access its function requires, and no more.

• Role definitions showing the access each function needs
• Evidence of least privilege enforcement, such as scoped roles rather than broad administrative rights
• Analysis of granted versus used permissions
• Records of privilege reduction actions

• Broad administrative roles granted because scoped roles were never built
• Permissions granted for a one-off task and never withdrawn
• No measurement of granted versus actually used access

Run an access provisioning process that authorises each grant, records it, and communicates changes to data and asset access to the affected parties.

• The provisioning procedure with the authorisation step
• Provisioning records showing requester, approver and date
• Evidence access changes were communicated
• Coverage across systems, not only the central directory

• Access granted by direct request to an administrator outside the process
• Approvals recorded without identifying the approver
• Provisioning in secondary systems done informally

Remove or adjust access promptly when a person moves role, leaves, or a system identity changes.

• The joiner mover leaver procedure and its timeframes
• Deprovisioning records matched against recent leavers and movers
• Evidence of timeliness, such as time from termination to access removal
• Reconciliation between HR records and active accounts

• Leaver access removed from the main directory while application accounts persist
• Movers accumulating access from every role they have held
• No reconciliation, so orphaned accounts are not found

Recertify user access against least privilege and separation of duties at a frequency set by the organisation's risk tolerance, and withdraw what is no longer justified.

• Completed access review campaigns with reviewer and date
• The frequency chosen and the risk tolerance behind it
• Evidence access was actually revoked following review
• Coverage of privileged and standard access

• Reviews approved wholesale with nothing revoked, indicating a rubber stamp
• Frequency set uniformly with no risk basis
• Revocation decisions recorded but not carried out in the system

Separate privileged roles so that administration of data, of encryption and key management, and of logging are held by distinct roles rather than one super-administrator.

• The privileged role definitions showing the separation
• Assignment records proving no individual holds conflicting roles
• Technical enforcement of the separation
• Evaluation evidence such as a conflict report

• A platform administrator role that implicitly carries key and log administration
• Separation defined and then defeated by an emergency access role
• No conflict reporting, so accumulation is unnoticed

Grant privileged access for a bounded period only, and prevent privileged rights accumulating in a way that defeats the separation between them.

• The time-bound privileged access process, such as just in time elevation
• Records of elevation requests with duration and expiry
• Evidence rights actually expire
• Controls preventing accumulation of segregated privileges

• Standing privileged access granted permanently
• Elevation granted with an expiry that is never enforced
• Accumulation across multiple elevation grants unmonitored

Let cloud customers take part in approving high risk privileged access to their environment where the organisation's risk assessment says that is warranted.

• The procedure describing customer participation in privileged access approval
• The risk assessment defining which roles are high risk
• Records of customer approvals obtained
• The technical mechanism by which a customer approves or denies

• Capability described but no mechanism exists for a customer to use it
• High risk roles never defined, so the process never triggers
• Customer approval sought after access was already used

Make the logging infrastructure append-only for everyone including privileged users, and control the ability to disable logging through a procedure with separation of duties and a break glass path.

• Configuration showing write-only or append-only access to logs
• Evidence that privileged platform roles cannot alter or delete logs
• The procedure governing disabling of logging, with separation of duties
• Break glass records and their review

• Platform administrators able to delete log data
• Logging disable capability available with no procedure around it
• Break glass used without subsequent review

Give every user a unique identifier, or otherwise be able to tie the use of an account back to a named individual.

• Evidence that accounts map one to one with individuals
• The list of shared or generic accounts and the controls that attribute their use
• Records attributing shared account use to individuals
• Review of shared accounts for elimination

• Shared administrative accounts used with no attribution mechanism
• Generic accounts created for convenience and never reviewed
• Attribution possible in theory but the supporting logs are not retained

Authenticate access to systems, applications and data, using multifactor authentication at minimum for privileged users and sensitive data, and digital certificates or equivalent strength for system identities.

• Authentication configuration per system showing the factors required
• Evidence multifactor authentication covers all privileged users and sensitive data access
• The mechanism used for system identity authentication
• Exception records where multifactor authentication is not applied

• Multifactor authentication enforced at the perimeter but bypassable by direct application access
• Service and system identities authenticating with static shared secrets
• Exceptions granted with no expiry or compensating control

Manage passwords securely across their lifecycle through defined and evaluated processes and technical measures.

• The password lifecycle procedure covering issue, storage, change and reset
• Technical measures such as hashing, vaulting and reset verification
• Evaluation evidence that the measures work
• Handling of initial and reset passwords

• Initial passwords issued over unprotected channels
• Reset process verifying identity weakly, making it the easiest attack path
• Passwords stored recoverably in some application

Check that each access to data and system functions is authorised, not merely authenticated.

• Authorisation model documentation per application and platform
• Evidence authorisation is enforced server side rather than in the interface
• Testing evidence covering authorisation bypass
• Evaluation records for the authorisation mechanism

• Authentication treated as sufficient, with any authenticated user able to reach any function
• Authorisation enforced in the user interface only
• No testing for horizontal or vertical privilege escalation

Keep approved interoperability and portability policies covering communication between application interfaces, processing interoperability, development portability, and data exchange, usage, portability, integrity and persistence, and review them at least annually.

• The approved interoperability and portability policy covering all four required areas
• Annual review record
• Evidence of communication to architecture and engineering teams
• The standards or formats the policy mandates

• Policy covers data export and omits interface communication or development portability
• Annual review missed
• Policy states principles with no named formats or standards, so it cannot be applied

Provide cloud customers with application interfaces they can call programmatically to retrieve their own data.

• The published interface documentation for customer data retrieval
• Evidence the interface works and returns the customer's full dataset
• Access control on the interface
• Coverage of the data types a customer would expect to retrieve

• Interface returns a subset of the customer's data with no statement of what is excluded
• Retrieval available only by raising a support request
• Interface documented but not maintained against the current data model

Use cryptographically secure, standardised network protocols for managing data and for importing and exporting it.

• Protocol configuration for management, import and export paths
• Evidence deprecated or non-standard protocols are disabled
• The protocol standard and version in use
• Testing evidence such as a transport security scan

• Legacy transfer protocols retained for a single customer or system
• Encryption present but with weak cipher suites still enabled
• Import and export paths overlooked while the main service is hardened

Write into customer agreements what access to data the customer keeps when the contract ends, covering data format, retention period, scope of data retained and the deletion policy.

• Agreement clauses covering all four required elements
• Evidence the operational process can deliver what the clause promises
• Records of data returned or deleted at recent contract terminations
• The data format actually offered and its usability

• Clause promises a format the platform cannot actually produce
• Retention period stated in the contract and not enforced in the platform
• Deletion policy referenced but not written down anywhere

Keep approved infrastructure and virtualisation security policies and procedures, and review them at least annually.

• The approved infrastructure and virtualisation security policy
• Annual review record
• Evidence of communication to infrastructure teams
• The standards the policy references, such as hardening baselines

• Policy written for physical infrastructure and never extended to virtualised or cloud infrastructure
• Annual review missed
• Policy references baselines that do not exist

Plan and monitor resource availability, quality and capacity so the system delivers the performance the business requires.

• Capacity plans with the business performance requirement stated
• Monitoring output for availability, quality and capacity
• Thresholds and the action taken when they are approached
• Evidence capacity planning influenced a provisioning decision

• Monitoring in place with no plan, so capacity is managed reactively
• Performance requirement never stated, so adequacy cannot be judged
• Thresholds set with no defined response

Restrict traffic between environments to authenticated and authorised connections, encrypt and monitor it, and review the configuration at least annually with a written justification for every allowed service, protocol, port and compensating control.

• Firewall and network policy rule sets between environments
• The written business justification for each allowed service, protocol and port
• Annual review record of the rule set
• Evidence of encryption and monitoring on inter-environment traffic

• Rules accumulated over years with no justification recorded
• Any to any rules left in place from a migration
• Annual review performed on the perimeter only, not between internal environments

Harden host and guest operating systems, hypervisors and the infrastructure control plane to a documented security baseline enforced by technical controls.

• The hardening baselines per platform and the standard they derive from
• Compliance scan results against the baselines
• Technical enforcement such as configuration management or policy as code
• Exception records for deviations

• Baselines documented but compliance never measured
• Control plane excluded, with only guest operating systems hardened
• Deviations found repeatedly and never remediated or accepted

Keep production workloads and the environments used for development and testing apart, so that activity in one cannot reach the systems or data of the other.

• Architecture evidence of separation, such as distinct accounts, networks or clusters
• Access control differences between the environments
• Evidence non-production cannot reach production data or services
• Review of any permitted connection between them

• Shared identity or network paths that make separation nominal
• Non-production holding production data, defeating the purpose of separation
• Separation at the network layer only while the control plane is shared

Segment and segregate provider and tenant access, and access between tenants, so one tenant cannot reach another, and monitor those boundaries.

• Design documentation of the tenant isolation model
• Technical evidence of enforcement at compute, network and data layers
• Monitoring of cross-tenant access attempts
• Testing evidence such as a tenant isolation test

• Isolation enforced in the application layer only, with shared data stores underneath
• Provider administrative access crossing tenant boundaries unmonitored
• Isolation never tested adversarially

Migrate servers, services, applications and data to cloud environments over encrypted channels using current, approved protocols only.

• The migration procedure specifying approved protocols
• Evidence of the channels used for recent migrations
• The approved protocol list and its currency
• Records of any migration performed outside the standard path

• Bulk data migrations performed over unencrypted or legacy channels for speed
• Approved protocol list not maintained, so deprecated versions remain approved
• Migration procedure exists but large one-off moves bypass it

Identify high-risk environments and document them in the network architecture record.

• Network architecture documentation with high-risk environments identified
• The criteria that define a high-risk environment
• Evidence the documentation is current against the deployed architecture
• Controls applied specifically to the identified environments

• Architecture documentation that predates the current environment
• High risk asserted with no criteria behind it
• Environments identified as high risk with no differentiated control

Apply defence in depth against network attack, covering prevention, detection and timely response, through defined and evaluated processes.

• The layered network defence design showing prevention, detection and response
• Configuration of the defensive controls at each layer
• Evidence of detection working, such as alerts raised and handled
• Evaluation records such as testing or a purple team exercise

• Single layer of defence at the perimeter with nothing inside it
• Detection deployed with no defined response path
• Controls deployed and never evaluated for effectiveness

Keep approved logging and monitoring policies and procedures, and review them at least annually.

• The approved logging and monitoring policy with approver and date
• Annual review record
• The procedures implementing it across platforms
• Evidence of communication to operations and security teams

• Policy covers infrastructure logging and omits application and cloud control plane logging
• Annual review missed
• Policy sets retention that the platform does not actually deliver

Secure audit logs and retain them for the defined period through processes and technical measures that are evaluated, not merely declared.

• The retention period defined per log type and the requirement behind it
• Technical configuration of retention and protection
• Evidence logs survive the full retention period
• Evaluation records showing the measures were tested

• Retention configured shorter than the policy states
• Logs protected in the central store while copies at source are unprotected
• Retention never verified, so silent truncation goes unnoticed

Watch applications and their underlying infrastructure for security-relevant events, and alert responsible stakeholders when those events and their metrics cross defined thresholds.

• The list of security-relevant events monitored per application and platform
• Alert rules and their thresholds
• Routing showing which stakeholder receives which alert
• Records of alerts raised and the response

• Events collected but no alerting configured on them
• Alerts routed to a queue nobody owns
• Application layer events omitted while infrastructure is well covered

Limit audit log access to authorised staff and record who accessed what, so every access is attributable to an individual.

• Access control list for the log platform with justification per holder
• Access records showing individual attribution
• Review of log platform access
• Evidence shared accounts are not used to reach logs

• Log platform access granted broadly to engineering
• Access to logs itself not logged
• Shared service accounts used for log access, breaking attribution

Review security audit logs for activity outside expected patterns and follow a defined process to act on anomalies within a set time.

• The defined review and response process with timeframes
• Records of reviews performed and anomalies found
• Actions taken on detected anomalies and their closure
• The baseline of expected activity anomalies are judged against

• Detection working but no defined timeframe for response
• Anomalies recorded and closed with no investigation
• No baseline, so what counts as unusual is left to the reviewer's judgement

Synchronise every relevant information processing system to a reliable time source so log entries can be correlated.

• The authoritative time source and its reliability basis
• Configuration evidence across systems pointing at that source
• Monitoring for time drift
• Coverage across on-premises, cloud and appliance systems

• Some systems using a different or default time source
• Time zone handling inconsistent across log sources
• Drift unmonitored, so correlation quietly degrades

Decide, document and implement which system events and metadata are to be logged, and revisit that scope at least annually and whenever the threat picture changes.

• The documented logging scope listing event types per system
• Configuration evidence that the scope is implemented
• Annual review record and reviews triggered by threat changes
• The rationale for events excluded from scope

• Scope defined by what the tooling produces by default rather than by decision
• Scope documented but not implemented in several systems
• No review after a significant change in the threat environment

Make audit records carry the security-relevant detail needed to reconstruct what happened.

• The required log record fields, such as timestamp, actor, source, action and outcome
• Sample log records demonstrating those fields are present
• Evidence across the main log sources, not one sample system
• Gap analysis where a source cannot produce a required field

• Records lacking the actor or the outcome, so events cannot be attributed or judged
• Fields present in one source and absent in others
• Sensitive data logged in clear as a side effect of verbose logging

Have the system itself protect audit records from unauthorised access, modification and deletion.

• Technical protections such as immutability settings, write once storage or integrity hashing
• Evidence privileged users cannot alter records
• Testing evidence that modification attempts fail
• Alerting on attempted tampering

• Protection relies on procedure rather than a system control
• Immutability set on the archive while the live store is mutable
• No alerting, so tampering attempts leave no signal

Monitor the operation of cryptography, encryption and key management controls and report internally on how they are performing.

• The monitoring configuration covering cryptographic operations
• Internal reports produced and their audience
• Metrics or indicators reported, such as failed operations and expiring keys
• Evidence reporting drove an action

• Cryptographic operations unmonitored because the platform hides them
• Reports produced with no recipient who can act
• Monitoring covers availability only, not policy conformance

Log and monitor key lifecycle events so use of cryptographic keys can be audited and reported.

• Log evidence for key creation, activation, rotation, suspension, revocation and destruction
• Monitoring or alerting on key lifecycle events
• Reporting output on key usage
• Retention of key lifecycle logs

• Key usage logged while lifecycle transitions are not
• Lifecycle events logged by the key store but never collected centrally
• No reporting, so the logs are never actually examined

Log physical access through an access control system whose records can be audited.

• Physical access log samples covering entry and exit
• The access control system and its audit capability
• Retention period for physical access records
• Evidence the records are reviewed

• Access logged at entry only, so occupancy cannot be determined
• Records held by a facilities provider and not obtainable for audit
• Logs retained but never reviewed

Report failures and anomalies of the monitoring system itself and notify the accountable party immediately, through a defined process.

• The process for detecting and reporting monitoring failures
• Health checks or heartbeat monitoring on log pipelines
• Notification records for recent monitoring failures
• The accountable party named for monitoring health

• Log pipeline failures discovered only when someone looks for missing data
• No health monitoring on the monitoring system, so silence looks like calm
• Failures detected but notification delayed to the next business day

Keep an approved governing document covering how security incidents are managed, how electronic discovery is handled and how forensics is performed in cloud environments, and review it at least yearly.

• The approved incident management, e-discovery and forensics policy
• Annual review record
• Procedures covering evidence handling and forensic readiness in cloud environments
• Evidence of communication to the response teams

• Policy covers incident response and omits e-discovery and forensics entirely
• Forensic procedures written for on-premises systems and unusable in cloud
• Annual review missed

Keep approved procedures that get security incidents handled within defined timeframes, and review them at least annually.

• The incident management procedure with timeframes by severity
• Evidence timeframes are measured against actual incidents
• Annual review record
• Severity definitions the timeframes attach to

• Timeframes defined but never measured, so adherence is unknown
• Severity definitions vague enough that anything can be downgraded
• Annual review missed

Maintain an approved security incident response plan that names the internal departments, affected cloud customers and business-critical relationships such as the supply chain that may be drawn in.

• The approved incident response plan with its version
• The stakeholder set named in the plan, internal and external
• Evidence customers and supply chain relationships are addressed
• Distribution records for the current version

• Plan names internal teams only, leaving customer and supplier involvement undefined
• Superseded versions still in circulation
• Plan approved once and never maintained against organisational change

Test incident response plans at planned intervals and after significant organisational or environmental change, and update them on what the test shows.

• Test records with date, scenario and participants
• The planned interval and evidence it was met
• Findings from each test and their closure
• Evidence of a test triggered by significant change

• Tests run as tabletop discussion only, never exercising the actual mechanics
• Findings raised and carried forward untouched
• No test after a major platform or supplier change

Define information security incident metrics and monitor them over time.

• The defined incident metric set, such as detection time, containment time and volume by severity
• Reports showing the metrics over time
• The audience receiving them
• Evidence a metric trend prompted an action

• Metrics counting incidents without measuring the response
• Metrics reported once and not trended
• No action ever taken on a deteriorating metric

Triage security-related events through a defined process so real incidents are separated from noise and routed to the right response.

• The documented triage process with severity and routing criteria
• Triage records for recent events
• Evidence of the process operating within its expected time
• Evaluation of triage accuracy, such as reopened or misrouted cases

• Triage performed on analyst judgement with no documented criteria
• High event volume causing silent dropping rather than deliberate closure
• No feedback loop measuring whether triage decisions were right

Notify affected parties of security breaches, including breaches reaching the organisation through its supply chain, within the timeframes set by service agreements, law and regulation.

• The breach notification procedure with the timeframes from each obligation
• The obligations register showing notification requirements per jurisdiction and contract
• Notification records for actual breaches with timestamps
• Evidence supply chain breaches are captured and assessed for notification

• Regulatory timeframes documented while contractual ones are not
• Supplier breach not treated as a notifiable event for the organisation's own customers
• Notification decision made without legal input and recorded only informally

Keep current points of contact for regulators, national and local law enforcement, and other relevant legal authorities.

• The contact list for regulators, law enforcement and legal authorities
• Evidence the contacts are verified on a cycle
• Coverage across the jurisdictions the organisation operates in
• Records of contact having been used or tested

• Contact list assembled once and never verified
• Coverage limited to the head office jurisdiction
• Contacts held by one individual rather than by the organisation

Keep approved policies and procedures for applying the shared security responsibility model inside the organisation, and review them at least annually.

• The approved shared responsibility policy with approver and date
• Annual review record
• The procedures that apply the model in practice
• Evidence of communication to the teams that consume and provide cloud services

• Policy describes the model conceptually without stating how it is applied
• Annual review missed
• Model applied by architects informally with no procedure behind it

Apply and manage the shared security responsibility model along the whole supply chain behind the cloud service, and document how it is applied.

• Documentation of the model applied to each supply chain tier
• Evidence of management activity, such as periodic confirmation with suppliers
• Identification of where responsibility passes between parties
• Gaps identified and how they are closed

• Model applied to the direct relationship only, with fourth parties unexamined
• Responsibility boundaries assumed rather than agreed
• Documentation produced at onboarding and never revisited

Give cloud customers written guidance explaining how the shared security responsibility model applies to them across the supply chain.

• The customer-facing shared responsibility guidance
• Evidence it is published and reachable by customers
• Coverage of supply chain elements, not only the direct service
• Version and review history of the guidance

• Guidance written for the flagship service only
• Guidance stops at the direct relationship and ignores sub-providers
• Guidance not updated when the service or its suppliers changed

State, control by control, which responsibilities sit with the provider, which sit with the customer and which are shared for the service offered.

• The control by control responsibility matrix for the service
• Evidence every control in the framework carries an ownership determination
• The basis for each shared designation
• Review of the matrix as the service changes

• Matrix covering a subset of controls with the rest left undetermined
• Controls marked shared with no explanation of the split
• Matrix not updated after a service change altered the boundary

Review and validate the shared responsibility documentation for every cloud service the organisation itself consumes.

• The inventory of cloud services consumed
• Review records of each provider's shared responsibility documentation
• Validation evidence, such as confirmation that customer-side duties are actually performed
• Actions raised where a customer-side duty was unowned

• Provider documentation collected but never read against the organisation's own controls
• Shadow cloud services absent from the inventory
• Customer-side responsibilities identified with nobody assigned to perform them

Implement, operate and assess the parts of the shared responsibility model that fall to the organisation, rather than assuming a provider covers them.

• Evidence of implementation for each customer-side responsibility
• Operating records showing the controls run
• Assessment or audit results covering those controls
• Ownership assigned per responsibility

• Customer-side responsibilities documented but not implemented
• Implementation assumed from a provider certification that does not cover it
• No assessment, so effectiveness of the customer side is unknown

Maintain an inventory of every supply chain relationship the organisation depends on.

• The supply chain inventory with the service each supplier provides
• The process by which new relationships enter the inventory
• Criticality or risk rating per relationship
• Evidence of currency, such as reconciliation against procurement records

• Inventory covers contracted suppliers and omits services procured on expense cards
• Fourth party dependencies not captured
• Inventory not reconciled, so exits and additions are missed

Reassess the risk each organisation in the supply chain presents on a recurring cycle, not only at onboarding.

• The periodic supplier risk review schedule and completed reviews
• The risk factors assessed
• Evidence reviews are proportionate to supplier criticality
• Actions arising from reviews and their closure

• Risk assessed at onboarding and never again
• All suppliers reviewed at the same depth regardless of criticality
• Review findings recorded with no action taken

Make provider and customer service agreements carry agreed terms on scope and location of services, security requirements including shared responsibility, change management, logging and monitoring, incident management and communication, right to audit and third party assessment, termination, interoperability and portability, and data privacy.

• Executed service agreements showing each of the required provision areas
• A clause coverage checklist mapped to the required terms
• Evidence the terms are operationally deliverable
• Records of agreements that deviate and the approval for the deviation

• Agreements missing right to audit or interoperability terms
• Terms present in the master agreement and absent from order forms that supersede it
• Clauses agreed that the operation cannot actually deliver

Review agreements between the provider and its cloud customers at least annually.

• Review records for customer agreements within the last twelve months
• The population of agreements and the coverage of the review
• Changes arising from the review
• Owner of the review activity

• Review covers large customers only
• Review performed by legal with no security input
• Findings from review not carried into contract amendments

Assess internally at least annually whether standards, policies, procedures and service level activities are being conformed to and are working.

• Internal assessment reports from the last twelve months
• Scope covering standards, policies, procedures and service level activities
• Conformance and effectiveness conclusions, not just conformance
• Findings and their remediation

• Assessment tests conformance to documents without asking whether the control works
• Service level activities excluded from scope
• Assessment performed by the team that owns the process

Bind every provider in the supply chain, by policy, to the organisation's own standards for security, confidentiality, access, privacy, audit rights, personnel vetting and service levels.

• The policy stating the requirements imposed on supply chain providers
• Evidence the requirements are flowed into contracts
• Confirmation of compliance obtained from providers
• Handling of providers that cannot meet a requirement

• Requirements stated in policy and never flowed into supplier contracts
• Compliance asserted by the supplier and never evidenced
• Non-compliant suppliers used with no documented risk acceptance

Review the IT governance policies and procedures of supply chain partners on a recurring cycle.

• Records of partner governance reviews with dates
• The material reviewed, such as partner policies or assurance reports
• The cycle defined and evidence it is followed
• Issues raised and their resolution

• Assurance report accepted as a governance review without reading its scope or exceptions
• Reviews performed for some partners and not others
• No defined cycle, so reviews happen only when prompted

Run periodic security assessments across every organisation in the supply chain, following a defined process.

• The defined supplier security assessment process
• Completed assessments across the supplier population
• Assessment depth matched to supplier risk
• Findings tracked to closure with the supplier

• Assessment limited to a questionnaire with no verification
• Coverage incomplete, with some suppliers never assessed
• Findings raised with suppliers and never followed up

Keep approved policies and procedures for identifying, reporting and prioritising vulnerability remediation so systems are not left open to exploitation, and review them at least annually.

• The approved threat and vulnerability management policy with approver and date
• Annual review record
• The remediation timeframes and prioritisation rules the policy sets
• Evidence of communication to engineering and operations

• Policy sets remediation timeframes that are routinely exceeded with no exception process
• Annual review missed
• Policy covers infrastructure and omits applications or containers

Keep approved policies and procedures for protecting managed assets against malware, and review them at least annually.

• The approved malware protection policy
• Annual review record
• The asset classes in scope and the protection required for each
• Evidence of communication and enforcement

• Policy covers endpoints and omits servers or cloud workloads
• Annual review missed
• Policy names a product rather than a control requirement, so it ages badly

Have defined routes for both scheduled and emergency response to a discovered vulnerability, chosen according to the risk that vulnerability carries.

• The documented scheduled and emergency response paths with their trigger criteria
• Records of emergency responses invoked and the outcome
• The risk criteria that select between the two paths
• Evaluation evidence that the paths work under pressure

• Emergency path undefined, so urgent vulnerabilities queue behind routine work
• Trigger criteria absent, making the choice of path arbitrary
• Emergency path used so often it has become the normal route

Update detection tooling, threat signatures and indicators of compromise at least weekly, and more often where the threat requires it.

• Update records for detection tools and signatures showing frequency
• Configuration of automatic update where available
• Coverage across all detection tooling, not one product
• Monitoring that catches an update failure

• Updates automatic on some tools and manual and lapsed on others
• Update failures unnoticed because nothing monitors currency
• Weekly cadence documented while actual updates are monthly

Track third party and open source libraries used by applications for available updates, and act on them under the vulnerability management policy.

• A software bill of materials or dependency inventory per application
• Tooling output identifying outdated or vulnerable libraries
• Records of library updates applied and their timeframes
• Handling of libraries that cannot be updated

• Dependency scanning enabled on new repositories only
• Findings raised with no owner, so the backlog grows
• Transitive dependencies not scanned, so the real exposure is understated

Commission penetration testing by independent third parties on a recurring schedule.

• Penetration test reports from independent third parties
• Evidence of tester independence
• The scope tested and how it was chosen
• Findings tracked to remediation with retest evidence

• Testing performed internally and described as independent
• Scope narrowed to avoid the areas most likely to fail
• Findings closed without retest

Scan organisationally managed assets for vulnerabilities at least monthly through a defined and evaluated process.

• Scan schedules and completed scan records covering the last several months
• Asset coverage evidence comparing scanned assets to the asset inventory
• Authenticated scanning configuration where applicable
• Evaluation that the scanning finds what it should

• Coverage gaps between the asset inventory and what is actually scanned
• Unauthenticated scanning only, understating the findings
• Monthly cadence claimed with gaps in the scan history

Prioritise which vulnerabilities to fix first using a risk-based model built on an industry recognised framework rather than raw severity alone.

• The prioritisation model and the recognised framework it derives from
• Evidence the model includes context such as exposure and asset criticality
• Prioritised backlog showing the model applied
• Review of the model's effectiveness

• Prioritisation by base severity score alone, ignoring exploitability and exposure
• Model documented but the backlog is worked in a different order
• Asset criticality unavailable, so context cannot be applied

Track and report vulnerability identification and remediation activity, including notification to the stakeholders who need to know.

• The tracking system holding identified vulnerabilities through to closure
• Reports issued and their recipients
• Evidence stakeholders were notified of vulnerabilities affecting them
• Ageing analysis of open findings

• Tracking held in scanner output rather than a system with ownership and dates
• Reports produced for security only, never reaching asset owners
• No ageing view, so long-open findings are invisible

Define, monitor and report vulnerability identification and remediation metrics at set intervals.

• The defined metric set, such as time to remediate by severity and open finding age
• Reports at the defined interval
• Targets or thresholds against each metric
• Evidence a metric trend led to a change

• Metrics counting findings without measuring remediation speed
• Reporting interval defined and not kept
• Metrics reported with no target, so performance cannot be judged

Keep approved policies and procedures covering every endpoint that touches the organisation, and review them at least annually.

• The approved endpoint policy with approver and date
• Annual review record
• The endpoint types in scope, including mobile and personally owned devices where permitted
• Evidence of communication to endpoint users

• Policy covers corporate laptops and omits mobile or personally owned devices in use
• Annual review missed
• Policy states requirements the endpoint management platform cannot enforce

Publish and maintain the list of services, applications and application sources endpoints are allowed to use when reaching or holding organisational data, and evaluate that list.

• The approved application and source list
• Technical enforcement, such as application allowlisting or store restrictions
• Evaluation records showing the list is reviewed
• The process for requesting an addition

• List published with no technical enforcement behind it
• List never reviewed, so it blocks current tools and permits abandoned ones
• No request path, so users install outside the list as a matter of course

Validate that an endpoint device is compatible with the operating systems and applications it must run, through a defined process.

• The documented compatibility validation process
• Validation records for device models in use
• The supported operating system and application matrix
• Handling of devices that fall out of support

• Devices in use that cannot run a supported operating system version
• Validation performed at procurement only and never revisited
• No matrix, so compatibility is judged case by case

Maintain an inventory of every endpoint used to store or reach company data.

• The endpoint inventory and the system holding it
• Reconciliation between the inventory and devices seen on the network or in the management platform
• Coverage of mobile and personally owned devices where permitted
• The process for adding and retiring endpoints

• Inventory covers managed laptops while mobile devices are absent
• No reconciliation, so unmanaged devices reaching data are invisible
• Retired devices remaining in the inventory, obscuring real coverage figures

Enforce the organisation's policies and controls technically on every endpoint permitted to reach systems or to store, transmit or process its data.

• Endpoint management platform configuration showing the policies enforced
• Enrolment coverage against the endpoint inventory
• Evidence of enforcement, such as compliance state per device
• Handling of non-compliant devices

• Enrolment coverage well short of the inventory
• Non-compliant devices reported and left with access
• Policies configured in the platform but not applied to all device groups

Configure interactive endpoints to lock the screen automatically after a period of inactivity.

• The automatic lock configuration and its timeout value
• Compliance reporting showing the setting applied across devices
• The policy that sets the required timeout
• Exception records for devices where it is not applied

• Setting applied to laptops and omitted for mobile or shared devices
• Configured as a user preference rather than an enforced policy
• Exceptions granted for convenience with no compensating control

Put endpoint operating system changes, patch levels and application changes through the company's change management process.

• Change records covering endpoint operating system and application changes
• The patch deployment process and its link to change management
• Patch level reporting across the estate
• Emergency patch handling and its retrospective approval

• Endpoint patching run as a separate activity outside change management
• Patch compliance reported without any change record
• Emergency patches deployed with no retrospective record

Encrypt storage on managed endpoint devices so data on a lost or stolen device is not disclosed.

• Storage encryption configuration and its enforcement policy
• Compliance reporting showing encryption state per device
• Recovery key escrow arrangements and their protection
• Handling of devices that report as unencrypted

• Encryption enabled by default but unverified, so failures go unnoticed
• Recovery keys stored without adequate protection
• Unencrypted devices reported and left in service

Deploy anti-malware technology on managed endpoints configured to both detect and actively block malicious code, not merely report it.

• Anti-malware deployment coverage against the endpoint inventory
• Configuration showing detection and prevention both enabled
• Health reporting, such as devices with disabled or stale protection
• Records of detections and their handling

• Detection enabled with prevention disabled to avoid disruption
• Coverage gaps on servers or developer machines
• Stale or disabled agents unnoticed because health is not monitored

Run a correctly configured software firewall on managed endpoints.

• Firewall enablement and rule configuration per endpoint platform
• Compliance reporting showing the firewall active
• The rule baseline applied and its justification
• Handling of devices with the firewall disabled

• Firewall enabled with a permissive rule set that allows anything
• Disabled during troubleshooting and never re-enabled
• No baseline, so each device carries different rules

Deploy data loss prevention technology and rules to managed endpoints in line with a risk assessment.

• The risk assessment driving the data loss prevention rule set
• Deployment coverage across endpoints
• The rules configured and the data types they target
• Records of detections and the response to them

• Technology deployed in monitor mode indefinitely with no enforcement
• Rules generic rather than derived from the organisation's own data classification
• Alerts generated and never triaged

Enable remote geo-location on all managed mobile endpoints.

• Geo-location configuration in the mobile management platform
• Coverage across the managed mobile estate
• The procedure governing when location may be used and by whom
• Privacy and legal position on location tracking of staff devices

• Capability available but not enabled on the mobile fleet
• No procedure, so location data use is uncontrolled
• Legal or works council constraints unaddressed

Be able to delete company data remotely from a managed endpoint, through a defined and evaluated process.

• The remote wipe procedure with authorisation requirements
• Coverage showing which devices can be wiped
• Records of wipes performed and their confirmation
• Evidence the capability has been tested

• Capability assumed from the platform and never tested
• Selective wipe of company data unavailable, so only full wipe is possible on personal devices
• Wipes triggered with no authorisation record

Maintain the security posture of third-party endpoints that reach organisational assets, using technical measures, contractual terms or both.

• Identification of third-party endpoints with access to organisational assets
• Technical measures applied, such as posture checking at connection
• Contractual terms binding the third party to endpoint standards
• Evaluation evidence that the measures operate

• Third party access granted with no posture requirement at all
• Contractual terms present with no technical verification
• Third-party endpoints not identified, so the population is unknown