C5 (Germany)

Maintain inventory procedures that keep asset records complete, accurate, valid and consistent throughout the asset lifecycle, whether populated automatically or by the responsible owners, hold the attributes the risk procedure needs including the measures applied, and log every change to those records.

• Inventory extract showing owner, location, lifecycle state and the risk relevant attributes per asset
• Discovery tooling configuration and its reconciliation report against the recorded register
• Field level change history identifying who altered an inventory record and when
• Procedure defining the triggers that force an inventory update at acquisition, transfer and retirement

• Register rebuilt by hand in a spreadsheet and already out of date at the time of audit
• Instances created by automation or autoscaling never reach the register
• Entries carry hostnames only, without the ownership and protection attributes the risk procedure consumes
• Retired items still show as active because no retirement update is ever recorded

Document, communicate and issue acceptable use and safe handling instructions spanning approval for acquisition through disposal, classification and labelling, secure configuration, software versions and patching, unsupported software, installation restrictions, malware protection, remote wipe, physical transport, incident handling and irreversible deletion at decommissioning.

• Acceptable use and handling standard covering every stage of the asset lifecycle
• Hardening baselines it references for error handling, logging, encryption and authorisation settings
• Support lifecycle list showing how products past vendor support are treated
• Device management configuration for installation restrictions, malware protection and remote wipe

• Rules written for laptops with nothing said about virtual machines and container images
• No stated treatment for software that has passed end of vendor support
• Disposal described as reformatting rather than irreversible erasure of the data
• Standard approved but never made available to the personnel who handle the assets

Approve hardware before it enters the production environment through a process that identifies, analyses and mitigates the risks its introduction creates, granting approval only after verifying that error handling, logging, encryption, authentication and authorisation are securely configured for the intended use.

• Signed commissioning approvals for hardware recently placed into production service
• Pre release configuration verification checklist naming the tester and recording each result
• Risk analysis produced for the introduction of a new hardware type or model
• Build or imaging standard applied to the device before handover to operations

• Equipment racked and cabled into production while the approval is completed retrospectively
• Verification limited to a functional test, leaving security settings unchecked
• Urgent capacity additions routed around the approval process entirely
• Approval signed by the requesting engineer with no independent verification

Require documented approval under the applicable policies before hardware supporting production cloud service components is withdrawn from use, and make withdrawal include complete and permanent erasure of the data or proper physical destruction of the storage media.

• Retirement approvals for hardware withdrawn from the production estate during the period
• Sanitisation or destruction certificates that identify the media by serial number
• Erasure tool output recording the method used and the verification result
• Chain of custody documentation for media released to a disposal contractor

• Failed drives returned to the vendor under warranty without prior sanitisation
• Destruction certificates do not identify which specific media they cover
• Erasure carried out but the verification step is missing from the record
• Equipment physically removed before the withdrawal approval was obtained

Obtain a demonstrable commitment from internal and external personnel to the acceptable use and handling rules before they receive assets that the risk assessment identifies as security relevant, and evidence the return of those assets when the employment or engagement ends.

• Signed handling commitments held against individual personnel records
• Issue register linking every handed out device or token to its current holder
• Return receipts and offboarding sign off for departed employees and contractors
• Risk assessment determining which asset types require an explicit prior commitment

• Devices handed to new starters before any handling commitment is signed
• Leavers keep equipment with no recorded recovery attempt or write off decision
• Issue register never reconciled against the list of departures
• Commitments collected from employees only, leaving contracted personnel outside the control

Classify assets and label them where practicable, with the responsible owners determining protection needs under one uniform scheme that defines levels for confidentiality, integrity, availability and authenticity, reflecting the information each asset processes, stores or transmits.

• Classification scheme defining the graded levels for each of the four protection objectives
• Register export showing the protection level held against each asset and who determined it
• Photographs or screen captures of the labels actually applied to media and equipment
• Guidance mapping information types to the correct level under the scheme

• Scheme grades confidentiality alone and omits integrity, availability and authenticity
• Protection levels assigned centrally by a central team instead of by the asset owner
• Almost all assets sit at the lowest level because no determination was performed
• Physical media carry no marking, so the handling rules cannot be applied in practice

Name a member of top management as owner of business continuity and emergency management, accountable for establishing the process, enforcing its guidelines and ensuring sufficient resources, with leaders visibly encouraging staff to contribute to its effectiveness.

• Appointment record naming the executive who owns continuity and emergency management
• Role description setting out that owner's accountabilities
• Budget or resourcing decision funding the continuity programme
• Leadership communication urging staff participation in continuity activities

• Ownership delegated to an operational manager with no executive accountability
• Named owner has left the organisation and the role was never reassigned
• Programme resource requests repeatedly declined with no record of the decision
• No sign of leadership engagement beyond a signature on the policy

Document, communicate and provide business impact analysis rules covering risk based scenarios, critical products and services, dependencies, threats, effects of planned and unplanned outages over time, maximum tolerable outage, restoration priorities, recovery time and data loss targets, and resources needed to resume.

• Business impact analysis methodology document
• Completed analysis listing critical products and services with their dependencies
• Recorded recovery time and recovery point objectives per critical service
• Threat and scenario catalogue used as input to the analysis

• Recovery objectives set without reference to the maximum tolerable outage
• Dependencies on external partners omitted from the analysis
• Analysis lists internal systems rather than the services customers depend on
• Resources required for resumption never quantified

Implement a single documented continuity and contingency planning framework derived from the impact analysis and anchored to standards in a statement of applicability, covering scope, plan accessibility, named owners, communication and customer notification, recovery and interim procedures, activation, improvement and incident management interfaces.

• Plan set demonstrably built on the outputs of the impact analysis
• Statement of applicability naming the standards the planning follows
• Plan ownership and approval record with scheduled review dates
• Recovery procedure including manual workarounds and component restoration order

• Plans stored only in systems that become unavailable in the scenarios they address
• Restoration sequence for infrastructure components not prioritised or agreed with customers
• Each team keeps its own plan format, so there is no single consistent framework
• Customer notification channels absent from the plans

Review, update and test the impact analysis and the continuity and contingency plans at least annually and after significant organisational or environmental change, involving affected tenants and relevant third parties, documenting the tests and applying results to later continuity measures.

• Test schedule and completed test reports covering the past twelve months
• Evidence that affected tenants and relevant third parties took part in a test
• Change log showing plans updated after an organisational or environmental change
• Follow up actions raised from test findings with their closure status

• Testing limited to desk walkthroughs with no technical recovery attempted
• Customers and suppliers never involved, so external dependencies stay untested
• Plans reviewed annually but not refreshed after a major platform change
• Test findings written up but never actioned

Deploy risk-derived technical controls that promptly detect and respond to irregular inbound or outbound traffic patterns and distributed denial of service attacks, feeding their output into a SIEM so correlated events can trigger countermeasures.

• Risk analysis output that drove selection of the protective measures deployed
• Denial of service mitigation configuration together with its activation thresholds
• Inventory of network protection sources currently feeding the security event platform
• Correlation rule set plus one worked alert showing the response taken

• Traffic anomaly sensors installed while their telemetry never reaches the event platform
• Mitigation thresholds left at vendor defaults with no reference to measured traffic baselines
• Detections raised outside office hours with nobody rostered to receive them

Design, publish and issue binding connection requirements stating when security zones separate and customers are segregated, which protocols and communication relationships are permitted, how administration and monitoring traffic is kept apart, and which cross-site and cross-network traffic is allowed.

• Published connection requirement document listing permitted protocols for each zone
• Communication matrix defining allowed source and destination pairings
• Design showing administration and monitoring traffic carried on distinct paths
• Provisions governing site-to-site and cross-network communication

• Requirements describe zones in general terms without naming the protocols allowed in them
• Administrative traffic carried on the same segment as production payload flows
• Interconnections built by engineering teams with no reference back to the stated requirements

Separate trusted from untrusted networks into risk-based security zones, configure physical and virtual networks to restrict and monitor those connections, reassess that design at least annually, and periodically re-justify every service, port and protocol in use.

• Zone model distinguishing trusted, untrusted and any demilitarised areas
• Firewall and virtual network rule bases with evidence of their latest review
• Annual assessment report on the connection monitoring conception and configuration
• Register of services, ports and protocols carrying current business justifications

• Rule bases still carrying permissive any-to-any entries left over from migration work
• Annual assessment limited to physical networking and omitting virtualised overlays
• Insecure protocols retained with compensating measures asserted verbally but never written down

Control every network perimeter with security gateways, and grant cross-network system access only on the basis of a security assessment that reflects the requirements of the cloud customers concerned.

• Boundary diagram identifying each perimeter and the gateway enforcing it
• Gateway policy set applied to cross-network access requests
• Security assessment files supporting individual cross-network authorisations
• Customer requirement statements captured as inputs to those assessments

• Boundaries exist that no gateway inspects, typically newer direct interconnects
• Cross-network access permitted for operational convenience with no assessment on file
• Assessments make no reference to the requirements of customers whose data crosses the boundary

Run infrastructure administration and management consoles on networks held physically or logically apart from customer networks and reachable only with multi-factor authentication, and likewise separate the networks used to create or migrate virtual machines.

• Topology drawing showing management networks distinct from tenant-facing segments
• Access path evidence requiring more than one factor to reach a management console
• Configuration of the segment carrying virtual machine creation and migration traffic
• Rule set blocking routing between management and tenant segments

• Administrators connect to consoles from ordinary office workstations on the general corporate network
• Hypervisor migration traffic shares a segment with productive tenant traffic
• Out-of-band management interfaces answer with a single factor of authentication

Segregate the traffic of different cloud customers in shared network environments at network level following a documented segregation concept, so transmitted data retains its confidentiality and integrity between tenants.

• Documented tenant segregation concept for shared network environments
• Network configuration listing the per-tenant identifiers currently in use
• Test results demonstrating traffic cannot pass between two tenant segments
• Controls preventing a retired tenant identifier from being handed to another customer

• Separation depends on application logic rather than measures taken at network level
• Identifiers recycled after decommissioning, allowing traffic to surface in the wrong tenant
• A shared services segment lets tenants observe one another's traffic

Keep traceable and current documentation of the logical network used to provide the service, showing subnet allocation, zoning and segmentation together with the geographic locations holding customer data, to avoid administration errors and enable timely recovery.

• Current logical network drawing carrying a revision date and a named owner
• Subnet allocation register mapping address ranges to zones and purposes
• Evidence that the drawing is amended as part of every network change
• Statement of the physical sites at which customer data is held

• Drawings predate recent network work, so live routing differs from what is depicted
• Storage locations omitted, leaving customers unable to assess data residency
• No accountable owner, so updates depend on whichever engineer remembers

Document and issue data transmission policies with technical and organisational measures protecting transferred data against interception, manipulation, copying, alteration, redirection and destruction, with the protection demanded tied to the information classification scheme.

• Transmission policy naming the transfer channels and tools that may be used
• Cross-reference from classification levels to the transmission protection required
• Instructions for exchanging data with external parties, including removable media handling
• Guidance issued to staff who routinely move data between organisations

• Policy addresses electronic mail but ignores the file transfer and collaboration tools staff actually use
• Protection applied uniformly with no regard to how the information was classified
• Redirection and destruction risks unaddressed because the policy considers only eavesdropping

Explicitly define and document the legal, regulatory, self imposed and contractual requirements bearing on the information security of the cloud service, together with the procedures the provider uses to comply with each of them.

• Register of applicable legal, regulatory, self imposed and contractual security requirements
• Mapping of each requirement to the procedure that satisfies it
• Evidence of legal and regulatory horizon scanning keeping the register current
• Named owner recorded against each requirement

• Register lists statutes only and omits commitments made to customers in contracts
• Requirements identified with no procedure named against them
• Register not refreshed when the service began operating in a new jurisdiction
• Self imposed commitments made in public statements never captured

Document, communicate and provide audit planning and conduct rules that confine auditors to read only access within the agreed plan, place potentially disruptive activity into maintenance windows or off peak periods, and require audit activity to be logged and monitored.

• Audit policy defining read only access limits and scheduling constraints
• Agreed audit plan for a recent customer or third party audit
• Access provisioning record showing read only rights granted to auditors
• Logs of auditor activity on the system components in scope

• Auditors given standing administrative accounts for convenience
• Intrusive audit activity carried out in peak hours outside any maintenance window
• Auditor sessions not logged, so their activity cannot be reconstructed
• Audit scope agreed verbally with nothing written down

Have subject matter experts run internal audits at least annually to test whether the information security management system meets the identified legal, regulatory, self imposed and contractual requirements and internal policies, with findings risk assessed and corrective measures defined and tracked.

• Internal audit programme covering the full management system scope
• Internal audit reports issued within the last twelve months
• Independence and competence records for the auditors used
• Corrective action tracker showing findings through to verified closure

• Programme repeats the same familiar areas and leaves parts of scope unaudited
• Auditors review processes they operate themselves
• Findings logged without risk assessment or a due date
• Actions marked complete with no evidence that they worked

Report information security performance within the scope of the management system to top management on a regular basis, and carry that information into a management review of the system held at least once a year.

• Management review minutes addressing security performance
• Performance reporting pack presented to top management
• Attendance record evidencing top management presence at the review
• Decisions and resource allocations arising out of the review

• Review held less often than once a year or skipped in a busy period
• Reporting shows activity counts with no judgement on suitability or effectiveness
• Review conducted by the security function alone without top management
• Decisions taken but never assigned an owner or a deadline

Document, communicate and make available policies governing third parties whose services support the cloud service, covering procurement risk assessment, subcontractor classification, security and training obligations, legal duties, vulnerability handling, contractual wording, monitoring, and flow down to their own providers.

• Approved third party control policy with version history and publication record
• Distribution list showing which procurement and legal staff received the policy
• Template contract clause library covering security, training and vulnerability obligations
• Classification rubric distinguishing subcontractors from other suppliers

• Policy silent on flow down of obligations to a supplier's own subcontractors
• No documented rule for deciding when a third party counts as a subcontractor
• Policy exists but was never issued to the teams that sign supplier contracts

Assess every service provider and supplier for risk before it contributes to the cloud service, and revalidate at least yearly, covering protection needs of the information handled, consequences of a breach, and dependency given service scope, complexity, uniqueness and available alternatives.

• Completed pre engagement risk assessments for a sample of newly onboarded suppliers
• Annual reassessment schedule listing the date of the last review per supplier
• Protection needs analysis recording confidentiality, integrity, availability and authenticity ratings
• Dependency analysis noting substitutability and the alternative providers considered

• Supplier began delivering before its assessment was completed
• Reassessments overdue beyond twelve months for long standing suppliers
• Scores recorded with no analysis of the impact a breach would have on service delivery
• Dependency and absence of alternatives never evaluated

Maintain a register of the providers and suppliers contributing to the service, recording company name, address, processing and storage locations, contacts on both sides, service description, risk classification, start of use and compliance proof, and verify entries annually.

• Export of the supplier directory showing all mandatory data fields populated
• Record of the last completeness and accuracy check with reviewer name and date
• Directory entries showing data processing and storage locations for sampled suppliers
• Link from each directory entry to the contractual compliance proof held on file

• Directory kept in spreadsheets that omit the start of service usage date
• Named contact persons left unchanged after staff departures on either side
• Processing location recorded at company level rather than country or facility level
• No annual verification of directory content ever performed

Verify that third parties meet agreed security and legal obligations by reviewing service quality reports, management system certificates, independent assurance reports and their vulnerability and incident records, at a cadence set by risk class, feeding results into reassessment and treatment.

• Register of assurance reports and certificates received from suppliers with expiry dates
• Review notes evidencing evaluation of a supplier's service quality reporting
• Correspondence obtaining a supplier's vulnerability and incident handling records
• Mapping of monitoring frequency to each supplier's assigned risk class

• Certificates collected and filed but never read or evaluated
• Monitoring performed at a uniform cadence irrespective of supplier criticality
• Qualifications and exceptions in a supplier assurance report not carried into the provider's own risk treatment
• Monitoring outcomes never used to refresh the supplier risk rating

Define and document exit strategies for purchased services where the risk assessment found very high dependency, aligned with continuity planning and covering transition cost, impact, resource and timing analysis, assigned roles, success criteria, and performance indicators that trigger withdrawal.

• Documented exit strategy for each supplier rated as creating very high dependency
• Transition cost and timeline estimate supporting one such exit strategy
• Role assignment matrix naming who executes each transition activity
• Defined service indicators and thresholds whose breach would start an exit

• Exit strategies written only for contract expiry, not for sudden supplier failure
• No dependency threshold defined, so no supplier ever qualifies for an exit strategy
• Exit planning not reconciled with the continuity plans it is meant to support
• Criteria for judging a transition successful left undefined

Maintain and issue encryption and key management policies that mandate state-of-the-art algorithms and network protocols, tie encryption strength to the information classification scheme, cover the full key lifecycle, and reflect applicable legal obligations.

• Approved cryptography and key management policy carrying its last review date
• Table linking each classification level to the required algorithm and minimum key length
• List of permitted algorithms and protocol versions with the reasoning for their currency
• Record of the legal and regulatory cryptographic constraints taken into account

• Algorithms named without stating minimum key lengths or acceptable protocol versions
• No connection drawn between classified information and the encryption strength demanded of it
• Permitted algorithm list untouched while the ciphers it lists were being deprecated externally

Implement procedures and technical measures applying strong encryption and authentication to cloud customer data whenever it is transmitted over public networks, so traffic in transit can be neither read nor spoofed.

• Protocol and cipher suite configuration of public-facing service endpoints
• External scan output confirming deprecated protocol versions are refused
• Certificate inventory for the endpoints terminating customer traffic
• Flow design identifying which transmissions leave the provider network over public paths

• Legacy endpoints still negotiating outdated protocol versions for backward compatibility
• Encryption terminated at a load balancer and carried onward unprotected across a public link
• Peer authentication not enforced, so the identity of the far end is never validated

Encrypt cloud customer data while it is stored and keep the private keys known only to the customer, handling any exception through a specified procedure that is contractually agreed with that customer.

• Storage encryption design identifying where the customer holds the private key material
• Signed terms covering key custody and any agreed departure from customer-only knowledge
• Written exception procedure together with the log of exceptions actually invoked
• Demonstration that provider personnel cannot retrieve keys held by the customer

• Provider-managed keys presented as customer keys while the provider retains full retrieval ability
• Departures from customer key custody practised operationally without any agreed basis
• Encryption switched on for primary storage but absent on replicas, snapshots and archives

Operate key management spanning generation, certificate issuance, activation, storage isolated from application and middleware layers, authorised retrieval, rekeying, compromise handling, withdrawal and deletion, with separate rules stated where pre-shared keys are used.

• Key lifecycle procedure running from generation through to destruction
• Key register recording owner, purpose, cryptoperiod and next rotation date
• Proof that the key store operates separately from application and middleware tiers
• Key compromise response instruction and any compromise event that invoked it

• Keys generated on general purpose systems with no assured source of entropy
• Rotation intervals defined on paper while expired keys stay in productive use
• Pre-shared secrets circulated by mail or chat with no dedicated handling provisions

Route every investigation request received from a government agency to qualified internal specialists for a legal assessment that establishes whether the agency has an applicable and legally valid basis, and determines what further steps must follow.

• Written procedure routing agency requests to legal review before any action is taken
• Legal assessment records for received requests citing the basis relied upon
• Qualification records for the personnel who perform the assessment
• Intake log capturing the date, agency and channel of each request

• Requests actioned by operations staff before the legal review happens
• Assessment recorded as a yes or no with no legal basis cited
• Requests arriving through informal channels bypass the intake log
• No defined handling for requests from agencies outside the primary jurisdiction

Tell the affected cloud customers about a government investigation request without undue delay, withholding notice only where the legal basis invoked forbids disclosure or where there are clear indications of unlawful activity connected to use of the service.

• Notification records showing the date each affected customer was informed
• Documented justification for any case where notification was withheld
• Legal analysis of the disclosure prohibition relied on to stay silent
• Procedure defining the notification timeframe and the approving role

• Notification withheld by default whenever an agency requests confidentiality informally
• No record explaining why a notification exception was applied
• Customers told only after the data had already been handed over
• Silence maintained after the disclosure prohibition has lapsed

Grant access to or disclose cloud customer data for a government investigation only once the legal assessment has confirmed that an applicable and valid legal basis exists and that the request must be met on that basis.

• Signed disclosure authorisations dated before the data was released
• Traceable link between each disclosure and its completed legal assessment
• Approval matrix showing who is permitted to authorise a release
• Log of requests declined because no valid basis could be established

• Data released on the strength of the agency's assertion alone
• Approval given verbally with no signed authorisation retained
• No request has ever been declined, suggesting the assessment is not a real gate
• Release made while the legal assessment was still open

Operate procedures that confine a government agency to the data actually covered by its investigation request, and where the data cannot be clearly delimited, anonymise or pseudonymise it so only the customers under investigation can be identified.

• Extraction specification showing the scope filters applied to a disclosure
• Records of anonymisation or pseudonymisation carried out before handover
• Review evidence confirming unrelated tenants were excluded from the extract
• Procedure describing how to delimit data when the request scope is unclear

• Whole datasets or shared tables handed over because filtering was difficult
• Other tenants' records included in an export without redaction
• Pseudonymisation applied but the reidentification key supplied alongside it
• No documented check that the extract matches the scope of the request

Screen every internal and external worker who will access customer data or production system components before they start, checking identity documents, career history, claimed qualifications, police clearance or good conduct certificates and exposure to blackmail, within the limits of local law.

• Screening file for a sample of recent joiners including the verified identity document
• Police clearance or certificate of good conduct records showing issue dates
• Confirmation that academic titles and degrees claimed for the role were verified
• Staffing agency contract clause requiring equivalent checks, plus the agency attestations received
• Legal opinion recording which checks each jurisdiction permits

• Contractor personnel accepted on the agency word with no evidence retained by the provider
• Checks completed weeks after production access had already been granted
• Blackmail exposure never assessed for highly privileged administrators
• Screening evidence destroyed immediately so completion cannot be demonstrated

Bind internal and external personnel through their employment or engagement terms to the applicable security policies, and capture a documented acknowledgement of the security policy and its subordinate instructions before any access to customer data or production components is granted.

• Employment and contractor agreement templates showing the information security obligation clause
• Signed or electronically captured policy acknowledgements for a sample of personnel
• Comparison report of acknowledgement timestamps against account provisioning timestamps
• Onboarding checklist that makes acknowledgement a precondition for account creation

• Accounts opened first and the acknowledgement chased up afterwards
• Acknowledgement recorded against a policy version that has since been superseded
• Agency and freelance personnel sign no equivalent undertaking
• Acknowledgement taken once at hire and never renewed after major policy revisions

Run a security awareness and training programme differentiated by target group and completed regularly by all internal and external personnel, refreshed as policies and the threat picture change, and covering production system handling, customer data handling, current threats and correct behaviour during incidents.

• Curriculum showing separate modules for groups such as administrators, developers and support staff
• Completion report per employee and contractor covering the current training cycle
• Content change log linking updates to new threats or to revised instructions
• Phishing simulation or knowledge assessment results and the follow up actions taken

• A single generic module delivered to everyone regardless of role or privilege level
• Completion tracked for employees while contracted personnel sit outside the reporting
• Material unchanged for several years despite a materially different threat picture
• No enforcement path for personnel who ignore the training reminders

Apply a defined disciplinary policy when personnel breach security instructions or legal requirements, first establishing that a breach occurred and weighing its nature, severity and impact, tell personnel in advance what sanctions are possible, and document each case appropriately.

• Approved sanctions procedure describing the breach verification steps and the graduated measures
• Communication issued to personnel explaining what consequences a security violation can carry
• Case files for security related disciplinary matters showing investigation and outcome
• Evidence that human resources and the security function jointly assess reported violations

• Measures applied inconsistently between employees and contracted personnel
• No record of the fact finding that preceded the measure taken
• Personnel were never told which behaviour attracts a sanction
• Reported violations settled informally by line managers with nothing written down

Inform internal and external personnel which information security obligations from their engagement terms continue to apply after their employment ends or changes, and state how long each of those obligations remains binding.

• Contract clause specifying which duties survive departure and for what period
• Exit or role change form recording that the continuing duties were explained to the individual
• Leaver and internal mover checklist containing the notification step and its sign off
• Signed acknowledgements collected from a sample of recent leavers

• Surviving duties buried in the contract and never restated at the point of departure
• Internal transfers processed with no review of which duties the person retains
• Duration of the continuing obligation left unspecified
• Departures of external personnel handled by the agency with no provider side record

Base confidentiality undertakings for employees, external service providers and suppliers on documented requirements for protecting confidential information and operational detail, obtain acceptance at contract signature or before customer data access, review the requirements at least annually, and reissue and reconfirm updated undertakings.

• Documented analysis of the protection requirements the undertaking wording is built from
• Executed confidentiality undertakings for a sample of employees, suppliers and service providers
• Annual review record of those requirements together with the resulting decision
• Proof of reconfirmation obtained from signatories after the last wording change

• Wording copied from a generic template with no traceable requirements behind it
• Suppliers began work before their undertaking was executed
• Requirements updated but existing signatories never asked to reconfirm the new terms
• No register showing who signed which version of the undertaking

Document, communicate and make available a role and rights concept plus an access management policy covering unique usernames, least privilege, segregation of duties, approval steps, periodic entitlement reviews, inactivity lockout and multi-factor authentication for privileged users.

• Approved role and rights concept with version history and management sign-off
• Distribution and acknowledgement records showing the access policy reached internal and external staff
• Matrix identifying incompatible duties that must not be held by one person
• Register of individuals or systems entitled to approve entitlement changes

• Role and rights concept never reissued after a reorganisation changed the underlying job families
• Policy silent on service and machine accounts used in automated authorisation
• Split between approving and assigning entitlements described in prose but not fixed to named roles

Operate defined procedures for issuing and amending accounts and entitlements for internal staff, external staff and automated system components, so that every grant or change demonstrably conforms to the approved role and rights concept.

• Provisioning workflow definition covering joiners, movers and technical accounts
• Sample of completed access request tickets showing requested role and recorded approver
• Export of entitlements granted during the period reconciled against approved requests
• Screenshot of the request form fields that force selection from the defined role catalogue

• Entitlements set directly in the target system, bypassing the request workflow entirely
• Requester and approver are the same person on a portion of sampled requests
• Roles entered as free text instead of catalogue values, producing entitlements outside the concept

Automatically lock accounts of staff and automated system components left unused for two months, require authorised approval to reinstate them, revoke them outright after six months, and re-run the full granting procedure before any reissue.

• System configuration showing the dormancy threshold set at two months
• Report of accounts locked for dormancy in the period with their lock dates
• Unlock approval records naming the authorising person or system component
• List of accounts deleted at the six month point with evidence of full re-request where reinstated

• Dormancy locking applies only to interactive staff logins and skips technical accounts
• Locked accounts survive far beyond six months because deletion is a manual housekeeping task
• Service desk reactivates dormant logins on a phone call with no recorded authorisation

When a person's duties or a system component's tasks change, adjust or revoke privileged access within 48 hours and every remaining access right within 14 days, repeating the granting procedure before any right is restored.

• Human resources feed or transfer notification that triggers the entitlement change
• Timestamp comparison of role change effective dates against privileged revocation times
• Sample of internal transfers evidencing removal of residual rights inside the fourteen day limit
• Change records for system components whose function in automated authorisation was reassigned

• Transferred staff accumulate rights because new entitlements are added and old ones never removed
• Elapsed time measured from ticket creation rather than from the date the role change took effect
• Contractor assignment changes never reach the access team because no notification path exists

Review all assigned access rights at least once a year using authorised reviewers drawn from the owning organisational units who know the actual duties involved, and correct or withdraw any deviation found within seven days.

• Recertification campaign schedule with completion statistics for the most recent cycle
• Signed reviewer attestations from the organisational unit owning the reviewed population
• Deviation log capturing detection date alongside the date the right was actually amended
• Justification of how the reviewer population was chosen for knowledge of the reviewed duties

• Reviewers confirm whole lists in a single action with no sign of individual consideration
• Findings recorded correctly but the entitlement removal happens weeks after detection
• Campaign scope covers named human users only and omits accounts driving automated processes

Issue privileged access personally and for a risk-based limited period, tie each technical user to a named individual, log privileged activity, alert responsible personnel automatically on defined misuse indicators, and apply disciplinary measures where misuse is proven.

• Inventory of privileged roles stating the risk-based validity period set for each
• Mapping of every technical user to the responsible named employee
• Privileged session logs together with the alert rules configured over them
• Records of raised alerts, the misuse assessment performed and any disciplinary follow-up

• Shared administrator credentials in daily use, so actions cannot be traced to a person
• Elevated rights granted open-ended despite a stated requirement for time limitation
• Privileged activity is collected centrally but no rule notifies an accountable owner

Notify the affected cloud customer of every provider access to their unencrypted data, stating cause, time, duration, type and scope in enough detail for the customer to assess risk, within 72 hours or the contractually agreed period.

• Notification template showing the cause, time, duration, type and scope fields
• Log of provider staff reads and writes on customer content matched to notifications issued
• Elapsed-time evidence between the access event and the customer being informed
• Contractual record of customers who expressly waived this information duty

• Engineer access during incident handling is treated as operational and never reported
• Message confirms that access occurred but omits scope, leaving the customer unable to assess risk
• Exemption claimed on the basis of encryption when encryption had been disabled for that session

Hand out authentication secrets in a controlled manner that preserves confidentiality, force initial passwords to be replaced at first logon and to expire within fourteen days, inform users of resets, and store passwords as strong cryptographic hashes.

• Procedure for issuing initial credentials and the channel used to convey them to the recipient
• Setting that expires an unused initial password after at most fourteen days
• Hashing algorithm and parameters applied to stored credentials
• Copy of the message a user receives after a password change or reset

• Initial passwords identical or built from a predictable pattern across new starters
• Credentials held with a fast unsalted hash or reversibly encrypted in legacy components
• Technically unavoidable deviations accepted without the required risk analysis and compensating measures

Authenticate every user and automated system component, require two-factor or multi-factor authentication to reach the production environment, permit only passwords, signed certificates or equally strong methods inside it, and enforce risk-derived password rules through configuration.

• Authentication design stating which factors are demanded to reach production
• Password policy showing the risk assessment from which its parameters were derived
• Platform settings enforcing those password parameters on in-scope system components
• Certificate administration records held under the key management guideline

• Break-glass and emergency logins reach production behind a single factor
• Password rules published centrally but not technically enforceable on some platforms
• Machine certificates used for authentication issued outside the governed key management process

Follow an established procedure for planning personnel and IT capacity that forecasts future demand, identifies usage trends and prevents overload, with measures that keep agreed customer commitments intact when resources or staff fall short.

• Capacity forecast model with historical growth curves per resource pool
• Planning procedure naming the forecast horizon and its review cycle
• Minutes of the capacity review board approving hardware order lead times
• Staffing plan for operations and on call roles against projected workload

• Forecasting covers compute only while storage, network and licences are ignored
• Planning addresses IT resources and never personnel availability
• Procurement lead times excluded, so a forecast cannot prevent an actual shortfall
• Dedicated single tenant components left outside the planning scope

Operate defined technical and organisational safeguards that monitor resource consumption and the provisioning and de-provisioning of cloud services, demonstrating that what is delivered stays within contractual agreements and agreed service levels.

• Utilisation dashboard showing configured thresholds and current headroom per cluster
• Service level attainment report covering the assessment period
• De-provisioning workflow record showing resources reclaimed after an account closed
• Escalation record raised when a utilisation threshold was crossed

• Thresholds observed with no defined action once they are breached
• Capacity released by departing tenants never returned to the shared pool
• Service level attainment calculated by hand from figures that cannot be reproduced
• Alert points set above the level at which performance already degrades

Give the cloud customer, so far as the service model permits, the means to monitor and steer the system resources allocated to it, so the customer can prevent resource contention and sustain adequate performance.

• Customer console screenshots of quota, scaling and resource limit settings
• Product documentation stating which resource controls exist for each service model
• Sample tenant metric feed or API response exposing allocated resource usage
• Change record for a resource adjustment initiated by a customer

• Customer facing metrics show consumption but offer no lever to act on it
• Controls documented for the flagship service while older services expose nothing
• Quota changes possible only through a support ticket with no stated turnaround
• Contention effects hidden from the customer because only aggregate figures are shown

Maintain approved and communicated malware protection policies stating which system specific protection mechanisms apply, how protection programs run on production components the provider is responsible for, and how they run on employee terminal equipment.

• Approved malware protection policy with version history and approval signature
• Distribution evidence showing the policy reached operations and end user support staff
• Inventory of system classes mapped to the protection mechanism selected for each
• Management console hardening standard referenced by the policy

• Policy covers office endpoints yet says nothing about production servers or container images
• No stated mechanism for systems that cannot run a resident scanner
• Policy approved years ago and untouched since the platform moved to containers
• Management consoles treated as outside the scope of malware controls

Configure production system components with malware protection as the policy prescribes, and where signature and behaviour based detection software is used, update its detection content at least once every day.

• Protection console export showing signature age for every managed host
• Production image baseline containing the scan schedule and exclusion set
• Coverage reconciliation between the asset register and protected hosts
• Detection and quarantine event sample with the follow up action recorded

• A tail of hosts running signatures days or weeks old with no exception recorded
• Coverage measured by agents installed rather than against the full asset inventory
• Resident scanning switched off on database and hypervisor hosts for performance, with nothing in its place
• New instances left unprotected until the next scheduled enrolment run

Document and communicate backup and recovery policies fixing backup scope, frequency and retention against contractual and internal RTO and RPO targets, requiring state of the art encryption of backups, restricting restores to authorised persons and mandating recovery testing.

• Backup policy stating retention per data class alongside the agreed RTO and RPO
• Encryption standard and key handling rules applied to backup sets
• Authorisation matrix naming who may trigger a restore
• Mapping of customer contract terms onto the internal backup schedule

• Retention in the policy shorter than the periods promised to customers in contract
• Policy silent on where backup encryption keys are held and who controls them
• Restore authority expressed as a role that no longer exists in the organisation
• Policy scoped to databases while configuration, secrets and infrastructure state are omitted

Watch backup execution through technical and organisational measures and have qualified staff investigate and rectify malfunctions promptly, so the agreed scope, frequency and retention of data backup are still achieved.

• Backup job status report for a sampled period showing successes, failures and reruns
• Ticket trail following a failed job through to successful completion
• Alerting rule configuration for backup failure notifications
• List of protected objects reconciled against the scheduled job definitions

• Failures visible in the backup console but never raised as tickets or owned
• Jobs reported successful while individual volumes or files were skipped
• Alerting configured only for hard failures so silent partial backups pass unnoticed
• No responsible owner outside business hours so weekend failures wait until Monday

Test restore procedures at least annually so that adherence to contractual agreements and to the defined maximum tolerable downtime and maximum permissible data loss can be assessed, and report any deviation to responsible personnel for prompt action.

• Restore test plan naming the systems, data sets and pass criteria
• Test report recording elapsed restore duration against the target
• Integrity verification evidence for the restored copy
• Corrective action log for shortfalls identified during the test

• Tests restore a single small file rather than a system to a usable state
• Elapsed duration never measured, so the recovery objective is not actually proven
• Testing performed on the very infrastructure a real disaster would remove
• Annual test skipped in a busy year with no approved deferral recorded

Hold backup copies at a remote location, transmitting them over the network with state of the art encryption or transporting media physically, choosing the distance by weighing recovery time against shared disaster exposure and matching the main site's physical security level.

• Location record and distance rationale for the offsite backup repository
• Transport manifest or courier chain of custody for physical backup media
• Encryption configuration of the backup replication link
• Physical and environmental security assessment of the remote storage facility

• Offsite copy kept in another room of the same building or campus
• Distance chosen for convenience with no analysis of shared flood, grid or seismic exposure
• Remote location protected to a lower standard than the primary data centre
• Media unprotected in transit because encryption is applied only at rest

Establish written logging and monitoring policies for systems in the provider's area of responsibility that define which events could breach protection goals, how logs are activated, paused and stopped, their purpose and retention, role responsibilities, time synchronisation and legal obligations.

• Logging policy listing the event types classified as security relevant
• Documented retention period per log source with the legal basis cited
• Responsibility matrix naming owners of log configuration and of log review
• Time synchronisation standard specifying the authoritative time sources

• Policy enumerates log sources yet never defines which events matter
• No rule stating who may pause or switch off logging on a system
• Retention periods in the policy inconsistent with the platform configuration
• No authoritative time source defined, so records across components cannot be correlated

Set documented rules for handling usage metadata that confine collection to billing, incident and security incident purposes, require anonymised data for operating and improving the service, forbid commercial use, fix a proportionate retention period and require deletion once the purpose ends.

• Metadata handling policy stating each permitted purpose and its retention clock
• Data inventory classifying which usage attributes count as metadata
• Anonymisation or aggregation specification applied before service improvement analytics
• Contract clause governing provision of metadata to the cloud customer

• Usage data reused for product analytics or marketing beyond the permitted purposes
• Anonymisation claimed while tenant or user identifiers remain in the data set
• No deletion trigger, so metadata accumulates for as long as storage allows
• Metadata shared with affiliated companies without a contractual basis

Implement the logging and metadata rules through technically supported procedures so that only authorised users and systems can reach the records, records are retained for exactly the specified period, and they are deleted once retention is no longer needed.

• Permission listing for the log platform showing groups and their read or admin rights
• Retention and lifecycle rules configured inside the log store
• Deletion job output confirming expired records were removed
• Access review record covering log platform accounts

• Anyone in operations able to read raw logs regardless of their role
• Retention written into policy but never configured in the tool, so data lives indefinitely
• Archived log buckets exempted from the lifecycle rules
• Service accounts holding standing log export rights that are never reviewed

Analyse logging data automatically against the defined event criteria, including correlation of relationships between events, and report identified events automatically to the appropriate departments for prompt evaluation and action.

• Detection rule set including the correlation logic for multi source events
• Alert queue extract showing elapsed time from event to notification
• Tuning history documenting rules added, amended or suppressed
• Handover record showing alerts reaching the on call responder

• No correlation configured, so only single event signatures are ever detected
• Alert volume so high that meaningful rules are suppressed wholesale
• Detection content never extended after new services were onboarded
• Events generated with no defined recipient outside business hours

Consolidate log data from every source into a central store in an unchangeable and aggregated form for authorised evaluation, delete it once its purpose expires, authenticate between logging servers and logged assets, and transmit over encryption or a dedicated management network.

• Architecture diagram of log forwarding paths into the central collector
• Immutability or write once configuration of the log repository
• Mutual authentication configuration between logging agents and collectors
• Integrity verification output for an archived log batch

• Logs held only on the originating host where an intruder can alter them
• Forwarding over unauthenticated plain syslog on the production network
• Central store writable by the same administrators whose actions it records
• Whole device classes such as network appliances never forwarded to the collector

Produce log data that identifies user access unambiguously at tenant level to support forensic analysis after a security incident, and provide interfaces for conducting forensic analysis and taking backups of infrastructure components and their network communication.

• Sample log record showing tenant identifier, acting principal, source address and action
• Documented forensic acquisition procedure naming the tooling used
• Description of the packet capture or snapshot capability for infrastructure components
• Case file from a past investigation attributing actions to a named individual

• Shared administrative accounts making attribution to an individual impossible
• Tenant identifier absent from records produced by shared platform services
• No means of capturing volatile memory or traffic before a host is rebuilt
• Investigator activity itself unlogged, so the investigation cannot be reconstructed

Restrict access to the system components used for logging and monitoring to authorised users, and make every change to their configuration through the applicable change management policies.

• Role membership list for administrators of the monitoring platform
• Approved change tickets covering the most recent alterations to log collection rules
• Audit trail of edits to detection rules and log source settings
• Segregation evidence separating log administrators from system administrators

• Detection rules edited directly in the console with no change record raised
• System owners able to alter or remove logging configuration on their own hosts
• Leavers keeping administrative rights on the monitoring platform
• No approval gate for changes that reduce log coverage

Monitor the system components used for logging and monitoring themselves, and report their failures automatically and promptly to the responsible departments so the loss of visibility is assessed and the required action taken.

• Heartbeat or watchdog configuration that detects a stalled log collector
• Incident record for a monitoring outage with detection and restoration times
• Availability report for the monitoring platform itself
• Log volume trend showing collection gaps and their explanation

• The monitoring platform watched by nothing, so its own outage passes in silence
• Agents that stop sending without any absence alert being generated
• Collector storage exhaustion dropping events with no notification
• No defined maximum acceptable blind period during a monitoring failure

Publish technical and organisational rules for vulnerability handling requiring regular identification of vulnerabilities, assessment of their severity, prioritised remediation or mitigation within defined timelines, and a defined treatment for components where no timely fix will be applied.

• Vulnerability policy stating the severity scale and the deadline attached to each level
• Documented handling route for components that cannot be remediated, including compensating controls
• List of approved vulnerability information sources feeding the identification process
• Risk acceptance register recording deviations from the remediation deadlines

• Severity scale defined without any corresponding remediation deadline
• No documented path for end of life components that will never receive a fix
• Rules limited to operating systems and silent on libraries, images and firmware
• Risk acceptances granted verbally, never recorded and never time limited

Commission penetration tests at least annually by qualified internal personnel or external providers, following a documented test methodology across the components identified as relevant in a risk analysis, rating findings against defined criteria and remediating medium and high criticality findings within set time windows.

• Penetration test report with scope statement, methodology and dated findings
• Risk analysis that determined which components were placed in scope
• Qualification or certification records for the testers used
• Remediation tracker showing closure dates against the agreed time windows

• Scope narrowed to a public marketing site while the service planes go untested
• Findings rated by the tester and then quietly downgraded internally without justification
• No retest performed to confirm that reported findings were actually closed
• The team that builds the platform also tests it, with no independence

Measure, analyse and assess the procedures used to handle vulnerabilities and incidents to confirm they remain suitable, appropriate and effective, with accountable departments evaluating results at least quarterly, initiating improvements and verifying that those improvements worked.

• Quarterly metrics pack covering mean time to remediate and deadline compliance
• Minutes of the management review at which those metrics were discussed
• Improvement action register with named owners and due dates
• Evidence that a previously agreed improvement was verified as effective

• Metrics produced but never presented to an accountable department
• The quarterly cadence slipping to annual with no record of the missed reviews
• Improvement actions closed administratively without any effectiveness check
• Measurement reduced to counting findings rather than assessing whether the procedure works

Keep affected cloud customers informed at regular intervals on the status of incidents concerning them, involve them in resolution where appropriate and necessary, and tell them what action was taken once the incident is resolved, all as the contract provides.

• Notification timeline for a sampled incident showing each update issued to the customer
• Contractual communication commitments listing notification intervals and channels
• Status page history or portal notices published for the same incident
• Closure notice describing the actions taken and any customer follow up required

• Customers told at the start and at closure with nothing in between during a long incident
• Only the technical contact notified while the contractual escalation contact is missed
• Closure message omits what was actually done, leaving the customer nothing to act on
• Notification intervals promised in the contract absent from the incident procedure

Check production system components automatically for known vulnerabilities at least once a month under the vulnerability handling rules, assess severity against defined criteria and initiate remediation or mitigation within the time window that severity carries.

• Authenticated scan schedule together with the most recent coverage report
• Finding list showing severity ratings and the assigned remediation due dates
• Reconciliation between scanned targets and the configuration management database
• Patch deployment record for a sampled critical finding

• Unauthenticated scans returning far fewer findings than the estate actually holds
• Coverage omitting container images, short lived hosts and appliances
• Monthly scans run but findings never assigned an owner or a due date
• Hosts discovered by the scanner that appear nowhere in the asset inventory

Harden production system components to generally accepted industry standards, document the hardening requirements for each component, verify immutable images against those requirements when the images are created, and retain configuration and log files evidencing their continuous availability.

• Hardening baseline document per operating system, database and hypervisor type
• Build pipeline output showing the compliance check applied to a golden image
• Configuration drift report against the baseline for a sample of running hosts
• Record of approved baseline exceptions with technical justification

• A public benchmark cited without stating which settings were adopted or waived
• Baseline applied at build time only while running systems drift unchecked
• No baseline defined for newer component types such as orchestration platforms
• Exceptions granted informally, leaving the effective baseline unknown

Separate cloud customer data stored and processed on shared virtual and physical resources strictly, following a documented approach derived from the risk analysis, so that the confidentiality and integrity of that data are preserved between tenants.

• Tenant separation design describing the isolation mechanism at each layer
• Risk analysis output that justified the chosen separation approach
• Test results from a deliberate cross tenant access attempt
• Isolation configuration of tenant identifiers, network and storage for a sampled customer

• Isolation enforced in the application layer alone over a shared database with no row level control
• Separation design not revisited after a shared caching or messaging component was introduced
• Cross tenant access asserted in the design but never actually tested
• Administrative tooling able to traverse tenants without restriction or logging

Operate an information security management system aligned to ISO/IEC 27001 covering the organisational units, sites and processes that deliver the cloud service, and retain documented scope, statement of applicability and the latest management review results.

• ISMS scope statement listing the in scope legal entities, sites and cloud delivery processes
• Statement of Applicability with inclusion and exclusion justifications for every control
• Minutes, inputs and decisions of the most recent management review
• Valid certificate and certification body audit report for the management system

• Scope leaves out subsidiaries or data centre sites that in fact operate production components
• Statement of Applicability not reconciled with the control set actually in force
• Management review last held more than twelve months ago or held without recorded decisions

Top management adopts an information security policy and issues it to internal staff, external personnel and cloud customers, setting out why security matters, the security objectives and target level, the core security strategy, and the security organisation.

• Information security policy carrying dated approval by the executive board or equivalent body
• Publication or distribution record proving the policy reached employees and contracted personnel
• Customer facing copy of the policy or the portal location where customers obtain it
• Organisation chart naming the security roles and reporting lines the policy declares

• Policy signed off by a security manager instead of top management
• Security objectives and target protection level stated generically with no link to business goals
• External personnel and cloud customers are never given sight of the policy
• Declared security organisation no longer matches the current reporting structure

Document and communicate the interfaces and dependencies between delivery activities run by the provider and those run by third parties, covering how vulnerabilities, security incidents and malfunctions are handled, and notify affected parties of changes early enough to react before the change takes effect.

• Shared responsibility model or duty matrix splitting delivery tasks between provider and third parties
• Service descriptions and contract clauses that fix cooperation duties for incidents and malfunctions
• Change notifications issued to dependent organisations, with dates showing the lead time given
• Joint escalation and contact directory used for reporting faults across organisational boundaries

• Split of duties agreed internally but never shared with the counterpart organisation
• Interface changes announced only after they were already live
• No defined route for passing vulnerability information to jointly operated components
• Documentation pitched too abstractly for the specialists expected to act on it

Separate conflicting duties on the basis of the documented risk assessment, at minimum across rights administration and access approval, change development, testing and release, and system operation, and where separation is not feasible monitor those activities to detect misuse or unintended change.

• Conflict matrix mapping incompatible functions to job roles and to system entitlements
• Documented justification and acceptance for each duty conflict that cannot be separated
• Configuration of the compensating monitoring rules plus evidence that someone reviews their output
• Sample of change records showing different individuals built, tested and released the change

• Developers retain standing deployment rights into the production environment
• Administrators raise and approve their own entitlement requests
• Compensating monitoring defined on paper with no reviewer and no sign off
• Analysis covers business applications only and ignores infrastructure operations

Maintain working contact with relevant authorities and security interest groups to obtain current threat and vulnerability intelligence, and feed what is received into the risk handling and vulnerability handling procedures.

• Membership confirmations or subscriptions for security interest groups and advisory feeds
• Register of named authority contacts showing the date of the last exchange with each
• Advisories received during the period traced to the tickets or register entries they triggered
• Notes from information exchange meetings or briefings attended by provider staff

• Feeds subscribed to but nothing shows anyone reads or acts on them
• Received advisories cannot be traced to any vulnerability handling or risk decision
• Named contacts have left the organisation and were never replaced
• German public sector customers are served with no BSI channel established at all

Document, communicate and make available a risk management procedure that covers identification of confidentiality, integrity, availability and authenticity risks with named risk owners, likelihood and impact analysis, evaluation against defined acceptance criteria, treatment with residual risk acceptance, and recording of the activities performed.

• Approved risk management procedure setting out method, rating scales and prioritisation rules
• Risk criteria table defining likelihood and impact bands and the acceptance thresholds
• Risk record template or tool configuration that forces a named owner on every entry
• Approval and version history of the risk methodology document

• No stated acceptance criteria, so each risk is judged ad hoc
• Ownership recorded at department level instead of naming an accountable individual
• Method addresses confidentiality alone and omits authenticity and availability
• Procedure written but never distributed to the staff expected to apply it

Run the risk handling process as needed and at least once a year, addressing mixed customer protection needs, weaknesses in the separation of shared resources, attacks through publicly reachable interfaces, unavoidable duty conflicts and subservice dependencies, with risk owners reviewing treatment and residual risk annually.

• Current risk register entries carrying assessment dates inside the last twelve months
• Risk owner attestations confirming the annual adequacy review of treatment and residual risk
• Assessment output covering tenant separation weaknesses and internet reachable entry points
• Treatment plans listing responsible person, target date and completion status
• Dependency analysis for the subservice organisations supporting the cloud service

• Register carried forward unchanged with no evidence of a reassessment cycle
• Residual risk accepted by the security function rather than the accountable owner
• Reliance on subservice organisations never entered as a risk at all
• New service features launched without passing through the risk process

Derive documented physical and environmental security requirements for all premises and data centres from risk assessment and identified protection needs, addressing planning faults, intrusion, surveillance, climate control, fire, water, power and ventilation, including requirements imposed on third party site operators.

• Signed physical and environmental security concept listing the eight hazard classes
• Site level protection requirement analysis for each data centre
• Contractual security requirement annex imposed on third party landlords
• Record of the technology standards or building codes cited as the design basis

• Concept written once at build time and never revisited after new sites were added
• Third party operated colocation sites left outside the documented requirements
• Hazards such as water ingress and air filtration named with no requirement attached to them
• No traceable link from risk assessment results to the stated building requirements

Deliver the cloud service from two mutually redundant sites that both satisfy the provider's physical security requirements, sit far enough apart to give operational redundancy meeting agreed availability levels, and test that redundancy at least yearly.

• Site pair topology diagram showing the separation distance between redundant locations
• Failover test report from the most recent annual redundancy exercise
• Availability clauses of the service level agreement mapped onto the redundancy design
• Capacity figures proving the surviving site can carry full production load

• Second site sized only for partial load so failover silently degrades the service
• Redundancy asserted on paper but never exercised within the last twelve months
• Locations placed too close together to survive a single regional event
• Secondary location held to weaker physical security controls than the primary

Build the outer shell of cloud service buildings to physically resist and detect intrusion, with external doors, windows, walls and locking mechanisms that withstand a burglary attempt for at least ten minutes.

• Resistance class certificates for external doors, windows and locking cylinders
• Shell construction drawings showing the wall, roof and floor build up
• Coverage plan for intrusion detection on the outer skin of the building
• Maintenance and function test records for perimeter alarm contacts

• Resistance ratings claimed for the main entrance while service and loading doors are ordinary construction
• False ceilings or raised floors permitting a rated wall to be bypassed
• Roof lights and ventilation openings excluded from the resistance assessment
• Alarm zones disabled during building works and never re enabled afterwards

Control entry at every access point using an access control system whose documented rules grant least privilege authorisations, revoke unused rights after two and six months, enforce two factor authentication for areas holding customer data, escort visitors and log all entries.

• Badge system export showing authorisation holders per security area
• Report of automatically revoked credentials with the recorded inactivity dates
• Visitor register with escort names and pass return times
• Door reader event log for a sampled high security room

• Dormant contractor badges still active well past the stated inactivity limit
• Two factor reader on the machine room door bypassed through an adjacent office door
• Visitors recorded at reception yet not tracked by the badge system inside the building
• No periodic reconciliation of badge holders against current job roles

Protect buildings against fire and smoke with fire sections rated at least ninety minutes, early detection with automatic voltage release, an extinguishing or oxygen reduction system, alarm transmission to the local fire brigade, plus recurring fire inspections and drills.

• Fire compartment plan with the certified resistance rating of each barrier
• Commissioning certificate for the extinguishing or oxygen reduction installation
• Transmission test record confirming alarm receipt by the local fire service
• Attendance list and debrief notes from the most recent fire drill

• Cable and pipe penetrations through rated walls left unsealed after works
• Detection zones so coarse that one alert would shut power to an entire hall
• Extinguishing agent inspection overdue against the manufacturer interval
• Drills run for office staff only and never for data centre operations shifts

Document and install supply resilience for production systems, covering N+1 power and cooling, correctly sized UPS and emergency generators tested at least annually, manufacturer aligned maintenance, and protection of power and telecommunications cabling inspected at least every two years.

• Single line electrical diagram showing the N+1 arrangement per hall
• Load bank and black start test report for the generator set
• Battery capacity measurement results for each UPS string
• Cable distributor inspection record covering seals, earthing and patch documentation
• Fuel supply contract together with on site fuel stock readings

• Generator started monthly off load so genuine capacity is never proven
• UPS batteries beyond service life with no capacity measurement on file
• Distributors inspected for tidiness but not for signs of tampering or undocumented patching
• Resilience lost because both rack feeds trace back to one distribution board

Continuously measure and regulate the operating parameters of technical utilities and the environmental conditions of the buildings, automatically informing the responsible departments when a value leaves the permitted control range so it can be returned promptly.

• Building management system point list with the configured alarm thresholds
• Temperature and humidity trend export for a sampled cold aisle
• Alarm ticket showing routing to facilities and the time taken to return within range
• Calibration certificates for the environmental sensors

• Thresholds set so wide that a genuine excursion never raises an alarm
• Alarms routed to a mailbox that nobody watches outside working hours
• Sensing limited to room level so rack level hot spots go undetected
• No record of the corrective action that followed a logged excursion

Offer documented inbound and outbound interfaces that let customer systems and other services retrieve data over standardised protocols preserving confidentiality and integrity, with documentation detailed enough for customer specialists and kept aligned to the productive release.

• Published interface specification describing how customers retrieve their data
• Version record tying that specification to the release currently running in production
• Endpoint protocol settings for the interfaces offered to customers
• Worked extraction performed end to end through the documented interface

• Specification reflects an earlier release and omits fields that production now returns
• Data can be exported only by raising a support request rather than through an interface
• Interface published on an untrusted network path without the encryption the policy requires

Fix in the contract what data is returned when the relationship ends, in which format and scope, the period allowed for handover, the point at which customer access ceases and deletion begins, and the customer's own cooperation duties.

• Contract or annex specifying data format, scope and the return period on termination
• Clause naming the moment customer access ends and erasure commences
• Written statement of what the customer must do to cooperate during exit
• Review note confirming the exit terms still match current legal requirements

• Terms promise data return without naming a format, leaving the choice to provider discretion
• No deadline stated between the end of the relationship and the handover of data
• Customer obligations left undefined, so exit stalls the moment customer action is needed

Erase customer data at the end of the contractual relationship in line with the agreed terms, covering the customer environment, metadata and backup copies, using methods that defeat recovery by forensic means.

• Erasure procedure spanning the live environment, metadata stores and backup media
• Completion confirmation issued for a terminated customer within the agreed period
• Technical description of the wiping or key destruction method relied upon
• Backup retention schedule showing when residual copies finally expire

• Live data removed while backup copies persist to the end of an unchanged retention cycle
• Metadata, audit trails and derived indexes retained after the content itself is gone
• Removal limited to deleting pointers, leaving content readable from the underlying media

Issue secure development policies covering the whole service lifecycle and grounded in recognised standards, addressing security in requirements, design, implementation, testing and verification, in software deployment including continuous delivery, and in reacting to faults and vulnerabilities during operation.

• Secure development policy naming the standard or method it is built on
• Lifecycle description running from requirements through to operational vulnerability handling
• Deployment security instruction covering the continuous delivery route
• Proof that the policy was issued to internal developers and contracted development staff

• Policy stops at coding conventions and is silent on deployment and operation
• Delivery pipelines run under no documented security requirement at all
• No recognised standard underpins the policy, so its completeness cannot be judged

Where development of the service or individual components is outsourced, contractually bind the supplier to recognised secure engineering practice, to acceptance testing against agreed functional and non-functional requirements, and to evidence that known vulnerabilities were ruled out.

• Development agreement clauses covering secure engineering obligations
• Acceptance criteria agreed with the supplier for functional and non-functional requirements
• Supplier-supplied proof that vulnerability checks ran before delivery
• Acceptance sign-off completed by the provider for delivered components

• Supplier agreement fixes deliverables and dates but says nothing about engineering security
• Code accepted on functional testing alone, with no vulnerability evidence ever requested
• Development subcontracted below the primary supplier and left outside the agreed clauses

Publish change management rules for software deployment setting criteria for risk categorisation, the testing and approvals each category demands, separation between developing, testing and releasing, customer notification duties, documentation updates, and emergency changes held to the same security level.

• Change management rules stating risk categories with the matching test and approval levels
• Definition of how developing, testing and releasing duties are held apart
• Requirement text for informing customers about changes that affect them
• Emergency change instruction including its retrospective documentation obligation

• The emergency route is used routinely, sidestepping the approvals the rules set out
• A single engineer is permitted to build, test and release the same change
• Rules omit any obligation to refresh system, operational and user documentation

Run a recurring, audience-specific security training and awareness programme for internal and external staff on standards and methods of secure software development and delivery and on the tools involved, and refresh it as policies, roles and tooling change.

• Curriculum differentiated for developer, tester and operations audiences
• Attendance and completion records for the current training period
• Proof the material was revised after a tooling or policy change
• Coverage list confirming external development staff were included

• Generic security awareness counted as secure software development training
• Contracted developers left out of the programme entirely
• Course content unchanged after the delivery toolchain was replaced

Assess each planned change for its potential effect on the system components involved and assign it a risk category and priority, which then determine how deeply it is tested and what approvals it must carry.

• Risk assessment entry attached to each of a sample of changes
• Category and priority definitions applied to changes
• Trace showing the assigned category actually drove testing depth and approval level
• Advance information sent to customers ahead of top-category changes

• Every change assigned the same category regardless of its likely impact
• The assessment is completed after deployment purely to satisfy the record
• Top-category changes released without the advance customer information the contract requires

Test each change during development and deployment to a depth matching its risk rating, using suitably qualified staff or state-of-the-art automated testing, involve customers where contracts require it, and rate and remediate identified defects against defined severity criteria.

• Test plans and outcomes for a sample of changes drawn across risk categories
• Qualification evidence for testers or the specification of the automated test tooling
• Defect severity criteria and the ratings applied to findings
• Remediation tickets for defects that blocked a deployment decision

• Identical test depth applied to trivial and to high risk changes
• Findings logged without a severity rating, so no criterion exists for the deployment decision
• Known defects deferred indefinitely with no remediation deadline attached

Place source code management and software deployment tooling under the role and rights concept with enforced authorisation, and configure it so every change to production system components is logged and traceable to the person or component that executed it.

• Permission model applied to the code repository and the deployment tooling
• Audit log extract showing changes attributed to identified actors
• Setting that prevents history rewriting or removal of tool logs
• Review of who currently holds pipeline administration rights

• Deployments executed under a shared pipeline identity that masks the requesting engineer
• Repository administrators can rewrite history and erase the trail behind them
• Tool logs retained for a shorter span than the audit window they are meant to support

Maintain version control that records the dependencies between individual changes and allows affected system components to be returned to their previous state when errors or vulnerabilities are identified.

• Branching and tagging scheme showing how releases are identified
• Dependency records linking a change to the components it touches
• Written restoration procedure plus a record of one restoration actually performed
• Retention rules keeping prior releases available for restoration

• Infrastructure and configuration definitions maintained outside version control
• Restoration has never been exercised, so its viability remains unproven
• Dependencies between changes untracked, so reverting one reintroduces an earlier defect

Require authorised personnel or approval components to release each change into the production environment against defined criteria such as test results and prior sign-offs, involving cloud customers in that release where contractual requirements provide for it.

• Defined criteria that a change must satisfy before entering production
• Sampled release records naming the approver and evidencing each criterion
• Current list of personnel or automated components entitled to release changes
• Customer sign-off records where the agreement calls for their involvement

• Approvals recorded after the change was already serving customers
• The entitled approver list is unmaintained, so departed staff keep release rights
• Automated promotion gates configured to pass even when test results are absent

Keep production environments physically or logically apart from development and test environments to prevent unauthorised access to customer data, malware spread and unintended component changes, and do not use production data inside those non-production environments.

• Environment inventory marking the boundary between production and non-production
• Access and network controls stopping non-production systems from reaching production
• Method for producing test data by anonymisation or synthesis
• Scan or review results showing non-production stores hold no live customer content

• Production copies loaded into test systems to reproduce a defect and then left in place
• Accounts and credentials that span both production and development estates
• Separation claimed logically while both estates share one platform with no enforcing control

Publish and keep current secure use guidance for customers on the productive service version, pitched at their security, compliance and audit specialists, covering secure configuration, vulnerability and update information sources, error handling and logging, authentication, elevated risk rights combinations, and privileged administration functions.

• Published secure configuration guidance matching the current production release
• Defined list of the topics the guidance must cover and their content owners
• Version comparison showing guidance updated alongside a service release
• Guidance section describing rights combinations that create elevated risk

• Guidance describes a superseded release and references settings that no longer exist
• Privileged administration functions left out of the guidance entirely
• Material written for end users rather than for security and audit specialists
• No pointer given to sources of vulnerability and update information

Build vulnerability detection into the software development process for the service, using a risk based mix of static and dynamic application security testing, expert code review and monitoring of confirmed flaws in third party libraries, then rate severity and remediate or mitigate immediately.

• Pipeline configuration showing static and dynamic security testing stages
• Findings report from a recent scan with severity ratings applied
• Code review records signed off by the reviewing specialist
• Software composition output listing advisories for third party libraries in use

• Security testing stages configured to warn only and never block a build
• Library advisories monitored for direct dependencies while transitive ones are ignored
• Severity taken from the tool default with no provider defined criteria applied
• High severity findings carried forward release after release without treatment

Operate or point to a daily updated online register of known vulnerabilities affecting the provider and assets customers install or run themselves, scored using CVSS, reachable by every customer, and stating per flaw whether an update exists, when it ships and who deploys it.

• Screenshot of the customer facing vulnerability register showing its last update timestamp
• Register entries carrying CVSS vectors and calculated scores
• Register fields stating patch availability, rollout date and the party who deploys
• Access route demonstrating that any customer can reach the register

• Register refreshed when convenient rather than every day
• Severity shown as a local high or low label instead of a CVSS score
• Register covers hosted components but omits agents customers install themselves
• Register placed behind a support portal many customers cannot open

Provide error handling and logging that lets customers see who accessed which data, service or function and when, malfunctions during automatic or manual actions, and changes to security configuration, logging, authentication, authorisation, cryptography and communication settings, with logs protected and customer deletable.

• Sample audit log entries showing actor, object, action and timestamp
• Configuration listing which security relevant changes generate a log record
• Access control settings that protect log stores from alteration
• Customer facing function allowing deletion or retention control of logs

• Logs capture system events but not access to customer data
• Changes to the logging configuration are themselves not logged
• Customers can read logs while administrators can alter them without trace
• Logging capability shipped disabled by default and left undocumented

Offer authentication mechanisms able to force strong multi factor authentication for the customers' users, IT components and applications, deploy them at every access point that interacts with the service, and make their use mandatory for privileged users, components and applications.

• Configuration evidence that multi factor authentication can be enforced per tenant
• Inventory of access points including APIs and legacy endpoints with their authentication settings
• Policy setting showing enforcement applied to privileged accounts
• Test result demonstrating rejection of a single factor privileged login

• Strong authentication offered on the web console but not for API or command line access
• Multi factor available as an option yet not enforceable for privileged roles
• Break glass accounts permanently exempted from the requirement
• Machine and application identities left on static long lived credentials

Protect interactions with the service using session management that meets at least the current state of the art and withstands known attacks, and invalidate a session once detected as inactive using a timeout configurable by the provider or, where technically possible, by the customer.

• Design documentation for session token generation, storage and invalidation
• Configuration showing the inactivity timeout value and who may change it
• Test evidence that a token is refused after logout or timeout
• Assessment against known session attacks such as fixation and replay

• Session appears closed in the interface while the underlying token stays valid
• Inactivity timeout set so long that it never triggers in practice
• Tokens not reissued after a privilege elevation
• Customers unable to adjust the timeout although the platform supports it

Where passwords authenticate to the service, users set their own or must replace an initial password expiring within fourteen days, length and complexity rules are technically enforced, users are notified of changes or resets, and hashes are stored with strong functions and 32 bit salts.

• Configuration showing initial password validity capped at fourteen days
• Technical enforcement settings for password length and complexity
• Copy of the message sent to a user on password change or reset
• Documentation of the hash function and salt length used for server side storage

• Initial passwords stay valid indefinitely until the account is first used
• Complexity rules stated in guidance but not enforced by the system
• Hashes stored with an outdated function or without a unique salt per password
• Users not informed when a reset is performed on their account by an administrator

Give cloud users a roles and rights concept for managing access, describing the rights profiles available for each service function so that permissions can follow least privilege and need to know, and operational duties can be kept separate from controlling ones.

• Published roles and rights concept listing a rights profile per service function
• Mapping of each profile to the individual permissions it confers
• Guidance identifying profile combinations that undermine separation of duties
• Customer documentation explaining how profiles are assigned and revoked

• Only broad administrator and read only profiles offered, forcing over privileging
• Rights profiles undocumented, so customers cannot apply least privilege
• Operational and controlling permissions bundled into a single profile
• Concept not extended when new service functions were released

Restrict service functions behind authorisation checks confirming that a user, IT component or application may perform the action, validate those checks before releasing new functions or changing existing ones, rate defects against an industry metric, remediate promptly and list unfixed ones publicly.

• Test cases and results validating authorisation checks before a feature release
• Regression evidence covering authorisation after a change to an existing function
• Severity ratings applied to authorisation defects using a standard scoring metric
• Entries in the public vulnerability listing for unresolved authorisation flaws

• Authorisation enforced in the user interface but not at the service endpoint
• New features shipped without an authorisation specific test case
• Defects fixed quietly and never disclosed in the published listing
• Object level checks missing, so substituting an identifier reaches another tenant's data

Where the service offers software defined networking, keep customer data confidential through suitable SDN procedures, validate the networking functions before releasing new ones or modifying existing ones, and assess and correct identified defects in a risk oriented way.

• Design documentation for tenant separation within the software defined network
• Validation test results for a new or modified networking feature
• Defect records showing risk oriented remediation decisions
• Configuration evidence of isolation between customer virtual networks

• Tenant isolation assumed from the underlying platform vendor and never tested
• Networking features shipped without validating the separation they affect
• Traffic separation defects triaged as functional bugs rather than security issues
• Overlay separation in place while management plane traffic remains shared

Where customers run virtual machines or containers, let the customer restrict which images its users may launch, inform the customer of what changed between versions of any images the provider supplies, and harden those provider supplied images to generally accepted industry standards.

• Customer facing setting restricting which images users are permitted to launch
• Release notes describing what changed between successive provider supplied images
• Hardening baseline and build evidence for one provider supplied image
• Catalogue showing the approved image set made available to a tenant

• Image restriction applies in the console while other launch paths ignore it
• New image versions published with no statement of what changed
• Provider images shipped with default accounts and unnecessary services enabled
• Hardening applied at first build and not maintained across later rebuilds

Let the cloud customer choose, from the options available under its contract, the location or country in which its data is processed, stored and backed up, and ensure the cloud architecture itself enforces that choice.

• Contract or ordering options listing the selectable processing and storage regions
• Architecture documentation showing regional placement is technically enforced
• Configuration evidence that backup copies remain within the chosen region
• Record confirming a tenant's actual data placement matches its selection

• Primary storage pinned regionally while backups or replicas leave the region
• Placement honoured by process alone with nothing preventing a cross region deployment
• Support tooling and telemetry data processed outside the selected location
• Customers given a choice with no means of verifying where data actually resides

Document, communicate and provide an incident response policy with technical and organisational safeguards for fast and proper handling, defining classification, prioritisation and escalation rules, interfaces to incident and continuity management, a standing computer emergency response team, and timely customer notification.

• Incident management policy setting out classification and prioritisation criteria
• Escalation matrix showing thresholds and the roles that receive each level
• Charter, staffing roster and contact details for the emergency response team
• Sample customer notification issued after a classified incident

• Severity levels defined but no criterion for who assigns the level
• Response team exists on paper with no named members or on call rota
• No documented interface between incident handling and continuity activation
• Timing of customer notification left entirely to case by case judgement

Have qualified internal specialists, drawing on external security providers where useful, triage each event that might be a security incident by classifying it, assigning priority and carrying out a root cause analysis.

• Ticket records showing triage decisions and assigned priority for suspected incidents
• Root cause analysis write ups for a sample of closed incidents
• Skills or qualification records for the analysts performing triage
• Engagement terms with any external security provider assisting analysis

• Tickets closed as resolved with no cause identified beyond the symptom
• Priority assigned by the reporter and never reviewed by an analyst
• Events dismissed as false positives with no analysis recorded
• External specialist help arranged only mid incident, with no standing agreement

Once an incident has been worked through, record the resolution as the contract requires and issue that report to the customers affected so they can acknowledge it or confirm the outcome.

• Closure reports issued to customers after incident resolution
• Contract extracts defining the report content and deadline owed to customers
• Acknowledgement or confirmation responses received back from affected customers
• Tracker showing which affected customers were sent a report and on what date

• Incidents closed internally with no report reaching the affected customer
• Report sent only to the customer who reported it rather than all customers affected
• Report content falls short of what the contract commits to deliver
• No record of customer acknowledgement, so closure cannot be evidenced

Inform employees and external business partners of their agreed or contractually imposed duty to report promptly, to one previously designated central office, any security event they learn of that relates to the cloud service, and confirm that mistaken reports carry no penalty.

• Internal communication naming the central reporting point and the reporting duty
• Partner agreement clause imposing the same reporting obligation externally
• Acknowledgement records confirming staff received the reporting instruction
• Awareness material stating that unfounded reports are not penalised

• Reporting duty covers employees only and omits contractors and business partners
• Several parallel reporting channels exist with no single designated office
• The no penalty message is never communicated, which suppresses early reporting
• Instruction given once at hire and never repeated or refreshed

Operate mechanisms that measure and monitor the type and volume of security incidents and report them to support bodies, then use the resulting analysis to identify recurring or significant incidents and decide where further protection is needed.

• Trend statistics on incident volume and category across consecutive periods
• Submissions made to national or sector support bodies
• Analysis identifying repeat patterns across separate incidents
• Decision records where that analysis led to new or strengthened safeguards

• Incident counts produced but never analysed for repetition
• Categorisation too coarse to reveal a recurring underlying cause
• No reporting route to external support bodies established
• Analysis findings never converted into protection improvements

Derive policies and instructions from the security policy in a uniform structure stating objectives, scope, roles with qualification and deputy rules, dependencies on customers and subservice organisations, execution steps and legal duties, version control and approve them, and issue them to internal and external staff.

• Policy hierarchy map showing how each instruction derives from the top level security policy
• Document control register recording version, author, approving body and effective date
• Authoring template that fixes the mandatory section headings for every security document
• Repository permissions or access log proving external personnel can retrieve applicable instructions

• Working copies kept on personal drives outside the controlled repository
• Each document follows its own layout so mandatory sections are missing from some
• Deputy and substitution arrangements for security roles are stated nowhere
• Subcontracted staff have no practical route to reach the instructions binding on them

Have subject matter experts review the security policies and instructions for adequacy at least once a year, weighing organisational and technical changes in how the cloud service is delivered and legal or regulatory change, and approve revised versions before they take effect.

• Review calendar listing every security document with its next review due date
• Completed review forms naming the expert who performed the assessment and the outcome
• Approval evidence dated before the effective date of each revised document
• Watch list of legal and regulatory developments considered during the review cycle

• Review date stamped but content untouched with no rationale for leaving it unchanged
• Revised instructions published into use and approved only afterwards
• Legal monitoring runs separately and never feeds the document review
• Reviews signed by owners who lack the technical knowledge to judge adequacy

Route every deviation from security policies, instructions and the related controls through the risk management process, secure risk owner approval and residual risk acceptance, record each deviation with a defined expiry, and have risk owners reconfirm its appropriateness at least annually.

• Exception register with unique identifiers, expiry dates and links to the corresponding risk entries
• Approval evidence signed by the accountable risk owner for a sample of granted deviations
• Records of the annual reconfirmation showing which deviations were closed, renewed or extended
• Request workflow or form design that blocks a grant without a linked risk reference

• Deviations granted open ended and quietly become the permanent operating state
• Expired entries left open while the underlying deviation continues in production
• Approval given by the requesting team instead of the risk owner
• Informal workarounds tolerated in operations and never registered as deviations