ISO 27002:2022

• Control implementation
• Control evidence
• Control attributes

• Controls inherited from a previous edition (2013) not refreshed against the 2022 attribute model.
• Detective controls present but corrective actions undocumented when triggered.

• Control implementation
• Control evidence
• Control attributes

• Controls inherited from a previous edition (2013) not refreshed against the 2022 attribute model.
• Detective controls present but corrective actions undocumented when triggered.

• Control implementation
• Control evidence
• Control attributes

• Controls inherited from a previous edition (2013) not refreshed against the 2022 attribute model.
• Detective controls present but corrective actions undocumented when triggered.

• Control implementation
• Control evidence
• Control attributes

• Controls inherited from a previous edition (2013) not refreshed against the 2022 attribute model.
• Detective controls present but corrective actions undocumented when triggered.

• Control implementation
• Control evidence
• Control attributes

• Controls inherited from a previous edition (2013) not refreshed against the 2022 attribute model.
• Detective controls present but corrective actions undocumented when triggered.

• Control implementation
• Control evidence
• Control attributes

• Controls inherited from a previous edition (2013) not refreshed against the 2022 attribute model.
• Detective controls present but corrective actions undocumented when triggered.

Requires an information security policy together with supporting topic specific policies. These must be defined, approved by management, published, communicated to and acknowledged by relevant personnel and relevant interested parties, and reviewed on a planned cycle and whenever significant change occurs.

• The approved information security policy, showing the approving authority and the date of approval
• The set of topic specific policies beneath it, such as access control, cryptography, backup, acceptable use and supplier security, each with an owner
• Evidence of publication and of communication to personnel and to relevant interested parties, such as intranet publication records or distribution lists
• Acknowledgement records from personnel and from relevant external parties confirming receipt and understanding
• The review record for each policy showing the planned cycle, the reviewer and the outcome, plus reviews triggered by significant change

• A single overarching policy exists while the topic specific policies it refers to were never written
• Acknowledgement captured at induction only, so no one who joined before the current version has agreed to it
• Review dates rolled forward with no evidence anyone read the document or considered whether change had occurred
• Contractors, temporary staff and suppliers excluded from communication because the distribution list is drawn from the payroll system

Requires rules for acceptable use, and procedures for handling information and its associated assets, to be identified, documented and put into effect.

• The acceptable use rules, covering personal use, removable media, cloud storage, email, messaging and use of artificial intelligence services where relevant
• Handling procedures per classification level, covering storage, transmission, printing, sharing and destruction
• Evidence rules were communicated and accepted by personnel and by third parties given access
• Technical enforcement evidence where the rules are enforced by tooling, such as removable media policy or upload restriction
• Records of monitoring or exception handling where the rules were breached

• Rules written for employees with contractors and third party users never asked to accept them
• Handling procedures defined for the top classification only, leaving everyday internal information with no guidance
• Rules silent on the services people actually use, such as personal cloud storage and consumer messaging apps
• No enforcement or detection, so the rules exist only on paper

Requires personnel and other relevant interested parties to return all organisational assets in their possession when employment, a contract or an agreement changes or ends.

• The leaver and role change procedure showing asset return as a mandatory step
• The checklist or ticket used per departure, listing assets issued to that person from the inventory
• Signed confirmation of return, and records for assets not returned including the escalation taken
• Evidence covering information as well as equipment, such as return or deletion of documents held locally and on personal devices
• Reconciliation between assets issued in the inventory and assets recovered

• Return tracked for laptops only, while access tokens, credentials, keys, documents and mobile devices are unmanaged
• Contractors and agency staff outside the human resources leaver feed, so no return process ever triggers
• Unreturned assets recorded as such with no follow up and no risk decision
• Information held on personally owned devices under a bring your own device arrangement with no removal step at all

Requires information to be classified according to the organisation's information security needs, judged on confidentiality, integrity and availability and on the requirements of relevant interested parties.

• The classification scheme, defining the levels and the criteria for each against confidentiality, integrity and availability
• Evidence the criteria account for the requirements of relevant interested parties, such as customers, regulators and contracts
• Classification applied to actual information assets in the inventory, not only defined in policy
• The process for reviewing and reclassifying information as its value changes
• Evidence of how classification decisions are made and by whom, normally the information owner

• Scheme defined against confidentiality alone, so integrity and availability requirements are never expressed
• Classification never applied, leaving every downstream handling and access rule with no input
• Too many levels, so users default to the highest or to none
• Contractual and regulatory requirements not mapped, so information subject to specific obligations is classified as ordinary internal data

Requires a matching set of information labelling procedures to be developed and implemented, so that information carries markings consistent with the classification scheme the organisation has adopted.

• The labelling procedures showing how labels are applied for each medium, covering documents, email, physical media, screens and system records
• Samples of labelled information from live systems, in each classification level in use
• Evidence labelling extends to information shared with third parties
• Technical labelling configuration where automated, such as document classification tooling, and its rule set
• Awareness and training evidence showing personnel know how to label

• Labelling defined for documents while email, databases and messages carry nothing
• Automated tooling deployed with users able to downgrade a label with no justification and no record
• Labels applied to new material with the existing repository left unlabelled and out of scope
• Labels applied inconsistently, so the label cannot be relied on to drive handling

Requires transfer rules, procedures or agreements to be in place for every type of transfer facility, covering transfers within the organisation and between the organisation and outside parties.

• Transfer rules covering each transfer type in use, being electronic, physical and verbal
• Transfer agreements with external parties, setting out protection, liability and traceability requirements
• Technical evidence of protection in transit, such as enforced transport encryption, secure file transfer configuration and managed file transfer logs
• Procedures for physical transfer, including courier selection, packaging and receipt confirmation
• Records of transfers of classified information, showing authorisation and receipt

• Rules cover email while file sharing services, application programming interfaces and system to system feeds are undocumented
• Agreements in place with major partners only, with ad hoc transfers to smaller parties uncovered
• Encryption in transit assumed from the platform and never verified in configuration
• Verbal transfer, including discussion of confidential matters in public or on calls, not addressed at all

Requires rules governing access to information and the assets tied to it, covering both physical entry and logical access, to be established and implemented on the basis of business need and security requirements.

• The access control policy and the specific rules derived from it, expressed per information asset or asset group
• Evidence the rules reflect business need and the classification of the information rather than convenience
• The mapping from rules to enforcement points, covering logical systems and physical areas
• Configuration evidence showing the enforced rule set matches the documented rule, sampled across key systems
• Records of how access rules are decided and approved, including who may authorise an exception

• Policy states principles such as least privilege while the actual rules per asset are never written down, so there is nothing to test enforcement against
• Physical access treated as a facilities matter and excluded from the access control rules entirely
• Rules defined for core systems while shadow systems, collaboration platforms and cloud tenancies are outside them
• Documented rules and enforced configuration diverge over time with no reconciliation

Requires the full life cycle of identities to be managed, from creation through change to removal.

• The identity lifecycle procedure covering creation, change and removal, for internal users, external users and non human identities
• Records showing each identity is traceable to a person or to an accountable owner where the identity is for a service or device
• Approval records for identity creation, sourced from an authoritative system such as human resources or contract management
• Evidence of timely removal on departure, with dates showing the interval between leaving and disablement
• Periodic reconciliation of active identities against the authoritative source, and the outcome of the last one

• Shared and generic accounts in use with no owner and no way to attribute an action to a person
• Service accounts, application identities and machine credentials created outside the process and never reviewed
• Identity removal driven by manual notification, so leavers stay active until someone remembers
• Reconciliation performed against the directory only, missing identities held locally in applications

Requires a management process to control how authentication information is issued and looked after over time, including guidance to personnel on handling it appropriately.

• The process for allocating authentication information, including initial issue, secure delivery and forced change on first use
• Rules on strength, reuse, expiry and storage, and the configuration enforcing them
• Evidence of secure storage, such as hashing configuration for stored credentials and a controlled vault for shared or privileged secrets
• Guidance issued to personnel on protecting authentication information, and evidence it was communicated
• Records of reset and recovery, including how identity is verified before a reset is performed

• Initial credentials sent by email or told verbally, with no forced change on first use
• Shared credentials for administrative or third party access held in spreadsheets or documents rather than a vault
• Reset process with weak identity verification, which is the route most commonly exploited
• Rules applied to the corporate directory only, with application local credentials unmanaged

Requires access rights to information and other associated assets to be provisioned, reviewed, modified and removed in accordance with the organisation's topic specific policy and rules on access control.

• Provisioning records showing the authorisation behind each access grant, tied to the access control rules
• Modification records where access changed after a role change, showing removal of the previous entitlements
• Removal records on termination, with the date of removal against the date of departure
• Access review evidence per system, showing who reviewed, what they saw, what was revoked and when the revocation took effect
• Evidence the reviewer had enough information to judge, such as entitlement descriptions rather than raw group names

• Role change results in access being added while the previous access is never withdrawn, accumulating entitlement
• Access reviews certified wholesale with everything approved and nothing revoked, which is the single most common finding
• Review outcomes recorded but revocations never actioned or never verified as actioned
• Privileged and third party access excluded from review, or reviewed by the team that holds it

Requires processes and procedures to be defined and implemented for managing the information security risks that arise from using suppliers' products or services.

• The supplier security process, covering identification, risk assessment, selection, onboarding and exit
• The supplier register with risk tiering, showing what drives the tier such as data access, criticality or connectivity
• Risk assessments performed for suppliers in the period, at the depth their tier requires
• Evidence of assurance obtained, such as certification, an assurance report or an assessment questionnaire with follow up on gaps
• Records of exit or termination handling, covering return or deletion of information and revocation of access

• Register limited to suppliers procurement knows about, missing services engaged directly by business teams
• Risk tiering assigned by contract value rather than by information access or operational criticality
• Certificates collected at onboarding and never reread, including certificates whose scope excludes the service actually bought
• Exit never exercised, so information and access persist after the relationship ends

Requires information security roles and responsibilities to be defined and allocated in line with what the organisation actually needs, so ownership of each security duty is explicit rather than assumed.

• The documented allocation of information security roles and responsibilities, naming individuals or positions rather than teams
• Role descriptions or terms of reference setting out the security duties attached to each role
• Evidence the allocation was formally approved and communicated to the holders
• Records showing asset owners, risk owners and control owners are identified and current
• Evidence of reallocation when a role holder leaves or changes position

• Security responsibility assigned to a function such as IT with no named accountable individual
• Role definitions written once at certification and never updated after reorganisation, leaving duties assigned to positions that no longer exist
• Holders unaware of the security duties recorded against their role
• Deputies and coverage for absence undefined, so the duty lapses when the holder is unavailable

Requires the relevant information security requirements to be established and agreed with each supplier, scaled to the type of supplier relationship involved.

• Executed agreements containing the agreed information security requirements, sampled across supplier tiers
• The clause set used, covering confidentiality, information handling, incident notification with a timeframe, subcontracting, personnel screening, return or deletion at exit and right to audit
• Evidence requirements were scaled to the relationship type rather than applied as one template regardless
• Records of negotiation outcomes where a supplier refused a clause, and the risk acceptance behind that
• Evidence that agreements are revisited when the service or the risk changes

• Security schedule attached to new contracts only, leaving the long standing critical suppliers on legacy terms with nothing in them
• Incident notification required with no timeframe, so late notification breaches nothing
• Subcontracting unaddressed, so a fourth party handles the information under no equivalent obligation
• Right to audit written in and never exercised, and in practice unexercisable

Requires processes and procedures to be defined and implemented to manage information security risk arising along the supply chain for ICT products and services.

• The process for managing ICT supply chain risk, distinct from general supplier management
• Requirements imposed on ICT suppliers regarding their own suppliers, component provenance and secure development
• Evidence of verification, such as a software bill of materials, component listings or attestation of development practice
• Records of monitoring for supply chain compromise affecting products in use, and the response taken
• Criteria for accepting or rejecting a product or component on supply chain grounds

• Supply chain risk assessed at the vendor level with no visibility of the components inside the product
• No software bill of materials requested, so exposure to a compromised library cannot be answered when it matters
• Requirements flowed to the direct supplier only, with no obligation to pass them down
• Hardware provenance, firmware and refurbished equipment not considered at all

Requires supplier information security practice and service delivery to be monitored, reviewed and evaluated on a regular basis, and requires change within them to be managed.

• The schedule of supplier reviews, showing frequency by tier and evidence the schedule was met
• Service reports and security metrics received from suppliers, and the review of them
• Records of issues raised with suppliers, and their resolution or escalation
• Evidence of how supplier change is managed, including notification of change, assessment of its security impact and approval where required
• Reassessment records where a supplier changed subcontractor, location or service model

• Reviews cover commercial performance and service levels with security never on the agenda
• Supplier self reported metrics accepted with no independent verification of anything
• Supplier changes discovered after the fact because there is no notification obligation or nobody monitors it
• Reviews scheduled annually and quietly skipped, with no record of the omission

Requires processes for the acquisition, use, management and exit of cloud services to be established in line with the organisation's own information security requirements. Supporting material frames the aim as preserving confidentiality, integrity and availability of information assets held in cloud services.

• The process covering cloud acquisition, use, management and exit, including who may acquire a cloud service
• The register of cloud services in use, with data classification, owner and criticality per service
• The shared responsibility position documented per service, showing which controls the provider operates and which the organisation must
• Configuration and monitoring evidence for the controls the organisation is responsible for
• The exit plan per material service, covering data extraction format, timescale and deletion confirmation

• Responsibility boundary assumed rather than documented, leaving controls neither party operates
• Register incomplete because services are bought on expense cards outside procurement
• Exit plan absent or untested, so extraction feasibility is unknown until the relationship fails
• Provider certifications relied on without checking the specific service and region are inside the certified scope

Requires the organisation to plan and prepare for incident handling ahead of time. Incident management processes, plus the roles and responsibilities attached to them, must be defined, put in place and communicated.

• The incident management process, defining categories, severity, escalation and the decision authority at each level
• Documented roles and responsibilities for incident handling, including out of hours coverage and named deputies
• Evidence the process and roles were communicated to those who must act on them
• Preparation evidence, such as playbooks for likely incident types, contact lists and readiness of forensic and communication capability
• Records of exercises or simulations testing the plan, and the improvements arising

• Plan written by the security team and never seen by the operational staff who would execute it
• No exercise, so the first test of the plan is a real incident
• Escalation defined to a role that has no authority to make the decision required, such as taking a system offline
• Out of hours arrangements undefined, which is when most incidents are detected

Requires information security events to be assessed and a decision taken on whether each event is to be categorised as an information security incident.

• The criteria used to decide whether an event is an incident, and the severity scale applied
• Records of events assessed in the period, including those assessed as not incidents, with the reason recorded
• Evidence of who performed the assessment and that they were competent and authorised to do so
• The point of contact or triage function receiving events from all sources, including monitoring, users and third parties
• Evidence of reassessment where new information changed the initial categorisation

• Only confirmed incidents are recorded, so the events dismissed at triage leave no audit trail and the decision cannot be reviewed
• Categorisation criteria informal, so the same event is treated differently depending on who is on shift
• Events from users and from suppliers entering a different route with no consistent triage
• Severity assigned at open and never revised as the picture changes

Requires information security incidents to be responded to in accordance with documented procedures, rather than improvised case by case.

• Documented response procedures per incident type, and evidence they were followed in actual incidents
• Incident records carrying detection, containment, eradication and recovery timestamps and the actions taken at each stage
• Evidence of decisions taken during response and by whom, including any decision to preserve rather than eradicate
• Communication records to internal stakeholders, affected parties, authorities and customers where required
• Closure records showing the criteria for closure were met

• Procedures exist but the incident record contains only an outcome, with no trace that the procedure was applied
• Containment achieved while the underlying weakness stays open, so the incident recurs
• Timestamps recorded at ticket creation and closure only, so response time cannot be measured
• Decisions made during the response undocumented, which is fatal if the incident later becomes a legal matter

Requires knowledge gained from information security incidents to be fed back into strengthening and improving the information security controls.

• Post incident review records for incidents meeting the defined threshold, with attendees and findings
• Root cause analysis distinguishing the technical cause from the process or control failure that allowed it
• Actions arising, with owner, due date and evidence of completion
• Evidence that findings changed something concrete, such as a control strengthened, a procedure amended or a detection rule added
• Trend analysis across incidents, showing recurring causes are identified as recurring

• Reviews held for major incidents only, so the frequent low severity incidents that reveal the systemic weakness are never analysed
• Root cause recorded as human error, which closes the analysis before it reaches the control that should have prevented it
• Actions raised and left open indefinitely with no escalation
• No trend analysis, so the same cause is rediscovered independently several times

Requires procedures to be established and used for identifying evidence relating to information security events, then collecting, acquiring and preserving it.

• Procedures for identification, collection, acquisition and preservation of evidence, covering the media types the organisation holds
• Chain of custody records for evidence collected in the period, showing who held it and when
• Evidence of the method used to acquire data in a way that preserves integrity, such as hashing and write protection
• Records of the competence of those performing collection, whether internal or an external provider on retainer
• Evidence of retention and secure storage of collected material for the required period

• Investigation performed on the live system, destroying the evidence in the act of examining it
• No chain of custody, so material collected is unusable in any disciplinary or legal proceeding
• Procedures cover servers and endpoints while cloud, software as a service and mobile evidence acquisition is unaddressed
• Retained material held without integrity protection, so it cannot be shown to be unaltered

Requires the organisation to plan how information security will be maintained at an appropriate level while a disruption is under way.

• Continuity plans showing how information security is maintained while the organisation is operating in a degraded or alternative mode
• The assessment of which security controls would be weakened or bypassed during disruption, and the compensating arrangements
• Evidence security requirements are part of continuity testing, not only recovery of function
• Records of emergency access arrangements, including how they are authorised, logged and withdrawn afterwards
• Post exercise or post event review confirming security was actually maintained

• Continuity plans restore availability while confidentiality and integrity controls are silently suspended
• Emergency access granted during an incident and never withdrawn once normal operation resumes
• Testing covers system recovery only, so no one tests whether logging, monitoring and access control survive the failover
• Alternative sites and manual workarounds operating outside the normal control environment with no assessment

Requires duties and areas of responsibility that would conflict if held by one person to be separated, limiting the scope for undetected error, fraud or abuse of privilege.

• The analysis identifying which duties and areas of responsibility conflict, covering both business and technical activities
• The conflict matrix and how it is applied to role design and to access provisioning
• System configuration or role definitions demonstrating conflicting duties cannot be combined in one account
• Records of compensating controls, and their approval, where segregation is not practicable because of the size of the organisation
• Evidence of periodic testing for actual segregation breaches, such as a report of users holding conflicting roles

• Conflicts defined for finance processes only, with no equivalent analysis for administrator activity such as change approval and change implementation
• Segregation designed into roles but broken in practice by emergency or firefighter accounts that carry every entitlement
• Small organisation compensating controls asserted verbally and never documented or tested
• No detective check, so a segregation breach persists undetected between annual reviews

Requires ICT readiness to be planned, implemented, maintained and tested against business continuity objectives and ICT continuity requirements. Supporting material frames this as ICT infrastructure and resources being resilient enough to carry business operations through disruption.

• ICT continuity requirements derived from the business impact analysis, expressed as recovery time and recovery point objectives per service
• The ICT continuity plans and the technical capability supporting them, such as replication, failover and alternative capacity
• Test plans and results for the period, showing objectives were measured against the requirement rather than assumed
• Evidence of maintenance, including plan updates after infrastructure or supplier change
• Records of gaps found in testing and their remediation

• Recovery objectives set by IT with no business impact analysis behind them
• Tests performed as a walkthrough or a partial failover that never proves the objective is achievable
• Dependencies on third parties and cloud regions excluded from the test scope
• Plans not updated after significant infrastructure change, so they describe an environment that no longer exists

Requires the legal, statutory, regulatory and contractual requirements bearing on information security, and the organisation's approach to meeting them, to be identified, documented and kept up to date.

• The register of legal, statutory, regulatory and contractual requirements relevant to information security, per jurisdiction of operation
• The documented approach to meeting each requirement, with the control or process that satisfies it
• Evidence the register is maintained, showing how new and changed obligations are identified and the date of the last update
• Records of legal or specialist input where the interpretation is not straightforward
• Evidence of assessment where the organisation operates across borders, including data transfer and cryptography restrictions

• Register lists laws with no mapping to any control, so compliance is asserted rather than demonstrated
• Horizon scanning absent, so the register reflects the position at the date it was created
• Contractual security obligations held in legal files and never extracted into the register, so operations do not know they exist
• Overseas jurisdictions omitted where the organisation processes data outside its home country

Requires appropriate procedures to be implemented to protect intellectual property rights.

• The procedure protecting intellectual property rights, covering both third party rights and the organisation's own
• Software licence records reconciled against installed and deployed software, including cloud subscriptions
• Evidence of controls preventing unlicensed installation, and detection where installation is possible
• Records covering open source use, including licence obligations attaching to components in developed software
• Awareness evidence showing personnel understand the restrictions on copying and reuse

• Licence position tracked for the major vendors only, with utilities, libraries and developer tooling unmanaged
• Open source obligations never assessed, so copyleft licensed components ship inside a proprietary product
• Reconciliation performed at renewal or under audit pressure rather than as a routine control
• Cloud subscriptions purchased per team with no central record of entitlement

Requires records to be protected against loss, destruction, falsification, unauthorised access and unauthorised release.

• The records retention schedule, showing retention periods and their legal or business basis per record type
• Evidence of protection appropriate to each record type against loss, destruction, falsification and unauthorised access or release
• Controls over the storage medium including its readability over the retention period
• Evidence of authorised and recorded destruction at the end of retention
• Access controls and audit trails over records systems, especially where records support legal or regulatory obligations

• Retention schedule exists while nothing is ever actually destroyed, so records accumulate beyond their lawful period
• Retention applied to the primary system while backups, archives and copies retain the record indefinitely
• Integrity of records relied on with no control preventing or detecting alteration
• Legacy media retained with no confidence the organisation can still read it

Requires the requirements for preserving privacy and protecting personally identifiable information to be identified and met, in line with applicable laws, regulations and contractual requirements.

• Identification of the privacy and personally identifiable information requirements that apply, per jurisdiction and per contract
• The record of processing activities, showing what personal data is held, why, on what basis and for how long
• Evidence of the protections applied, such as access restriction, minimisation, pseudonymisation and transfer safeguards
• Evidence of how data subject rights are handled and within what timeframe
• Records of privacy impact assessment where processing carries higher risk

• Requirements identified for the home jurisdiction while data of individuals in other jurisdictions is processed under no assessment
• Record of processing created for a compliance deadline and never updated as systems and purposes changed
• Personal data in unstructured stores, test environments and backups omitted from every protection measure
• Retention periods for personal data defined in policy but not enforced anywhere in the estate

Requires the organisation's approach to managing information security, and its implementation across people, processes and technologies, to be reviewed independently at planned intervals and whenever significant change occurs.

• The plan for independent review, showing the interval and the scope covering approach, people, processes and technologies
• Reports from reviews performed in the period, and the identity and independence of the reviewer
• Evidence of independence, meaning the reviewer does not review their own work
• Findings raised, their management responses and evidence of completed remediation
• Records of reviews triggered by significant change, in addition to those on the planned cycle

• Review performed by the information security manager on their own management system, which is not independent
• Scope limited to technical testing, so the approach to managing security is never itself reviewed
• Findings accepted with no remediation and no formal risk acceptance
• No review triggered by significant change, so a major restructure or migration is only picked up at the next annual cycle

Requires compliance with the organisation's own information security policy, topic specific policies, rules and standards to be reviewed regularly.

• The programme of compliance checks against the organisation's own policies, rules and standards, showing coverage and frequency
• Results of checks performed in the period, including technical configuration compliance against the defined standard
• Records of non conformities identified, their cause and the corrective action taken
• Evidence managers are accountable for compliance in their own area, with reporting to them
• Evidence of follow up verifying that corrective action was effective, not merely completed

• Compliance measured by asking system owners rather than by examining the systems
• Checks cover the policy areas that are easy to measure and skip the ones that matter
• Non conformities closed on the assertion of the owner with no verification
• Repeat non conformities in the same area never escalated, so the underlying cause is untouched

Requires the operating procedures used to run information processing facilities to be written down and made available to the personnel who need them.

• The set of documented operating procedures for information processing facilities, covering routine operation, backup, monitoring, incident handling and restart
• Evidence procedures are available to the personnel who need them, including during an outage of the primary system that hosts them
• Version control and review records, showing procedures are current against the systems they describe
• Evidence procedures are followed, such as completed run sheets, checklists or ticket records referencing them
• Records of update following change to the system or the process

• Procedures held only in the wiki or system that is itself unavailable during the incident they are needed for
• Documentation written at implementation and never updated, so it describes a superseded platform
• Knowledge held by one individual with the procedure never written down at all
• Procedures exist but operations run from memory, with no record tying an activity to the documented step

Requires management to compel all personnel to apply information security in accordance with the organisation's established policy, its topic specific policies and its procedures, rather than leaving adherence to individual discretion.

• Evidence that management sets the expectation that personnel apply the policy and procedures, such as briefings, team meeting records or management communications
• Records showing management assign security tasks and follow up on completion
• Evidence of management action where adherence was found lacking, and the route from that to the disciplinary process
• Management review minutes covering information security performance
• Objectives or performance measures for managers that include security responsibilities

• Policy issued centrally with no evidence any line manager reinforced it
• Non-adherence identified by audit or monitoring with no record of management follow up
• Management review held but minuted at a level that shows no decision was taken
• Expectations set for employees only, with contractors and outsourced staff left to their own employer

Requires the organisation to establish and maintain working contact with the relevant authorities, so that security matters can be raised and received through an established channel.

• The list of relevant authorities identified, such as regulators, data protection authorities, law enforcement and national cyber security bodies
• Named contacts and current contact details for each, with a review date
• Evidence of actual contact, such as registration records, correspondence or notification records
• The procedure describing when and how each authority is contacted, and who is authorised to do so
• Evidence the contact list is exercised or verified so it is known to work before an incident

• Contact list assembled once and never verified, so numbers and named officers are out of date when needed
• Contact restricted to reactive breach notification with no established working relationship
• Multiple people authorised to contact a regulator with no coordination, or no one authorised at all outside business hours
• Authorities relevant to overseas operations omitted because the list reflects the head office jurisdiction only

Requires ongoing contact to be maintained with special interest groups, with forums that specialise in security and with professional bodies, giving the organisation a route to current expertise and early warning of developments.

• The list of special interest groups, security forums and professional bodies the organisation participates in
• Membership records, subscriptions or attendance evidence for the period
• Records of information received through these channels and what was done with it, such as advisories fed into vulnerability management
• Evidence that participation is assigned to a role rather than to an individual's personal interest
• Any confidentiality assessment governing what the organisation shares in those forums

• Membership held but dormant, with no evidence of anything received or acted on
• Participation resting entirely on one enthusiast, and ceasing when that person leaves
• Advisories received into a mailbox nobody triages
• No control over what employees disclose about the organisation's environment in open forums

Requires information about information security threats to be collected and analysed so that it becomes usable threat intelligence. Supporting material frames this as gathering and applying intelligence proactively, to identify, assess and mitigate emerging threats before they are realised.

• The defined sources of threat information, covering strategic, tactical and operational levels
• The process for analysing raw information into intelligence relevant to the organisation, naming who performs it
• Intelligence products produced during the period and their distribution list
• Evidence that intelligence changed something, such as a rule added to detection, a control adjusted or a risk reassessed
• Feedback records showing whether the intelligence proved relevant, used to refine the sources

• Feeds subscribed to but never contextualised, so generic threat reports are filed with no assessment of applicability
• Intelligence consumed by the security team alone and never reaching risk management or the business owners who would act on it
• No traceable outcome, so the control cannot be shown to be effective even though the process exists
• Intelligence limited to technical indicators, with no view of threat actors targeting the organisation's sector

Requires information security to be integrated into the way projects are managed, so security is handled inside the project method rather than bolted on after delivery.

• The project methodology or gating documentation showing information security as a defined step, not an optional one
• Security risk assessments produced for projects in the period, including projects that are not IT projects
• Evidence of security requirements being set at initiation and verified before go live
• Records of security sign off at project stage gates, naming the approver
• Evidence that the same treatment applies to agile and to vendor led delivery, not only to waterfall projects

• Security engagement triggered by a checkbox that project managers can and do skip
• Assessment performed close to go live when the design is fixed and findings become accepted risks
• Business change and procurement projects excluded because the process sits inside IT
• Security requirements defined and then never verified against what was actually delivered

Requires an inventory of information and of the other assets associated with it to be developed and kept current, and requires that inventory to record ownership of each entry.

• The inventory of information and associated assets, showing scope across hardware, software, services, information stores and cloud tenancies
• The recorded owner for each entry, and evidence owners have accepted the role
• The process and cadence for keeping the inventory current, including additions and retirements
• Reconciliation evidence between the inventory and an independent source such as network discovery, endpoint management or the finance asset register
• Evidence that information assets, not only equipment, are inventoried, including data sets and repositories

• Inventory covers devices while the information those devices hold is never itemised
• Ownership recorded as a department, so no individual can be asked to make a decision about the asset
• Cloud services and software as a service tenancies acquired outside procurement never enter the inventory
• Reconciliation never performed, so the inventory drifts and disposals stay listed as live

Requires background verification checks on all candidates for personnel before they join and on an ongoing basis afterwards, within the bounds of applicable laws, regulations and ethics, and proportionate to business requirements, the classification of information to be accessed and the perceived risk.

• The screening procedure, showing what checks are performed and how the level is set against the classification of information accessed and the perceived risk
• Completed screening records for personnel who joined in the period, including contractors and agency staff
• Evidence of the legal and regulatory limits applied in each jurisdiction, and of candidate consent where required
• Records of ongoing or repeat verification where the role warrants it, with the trigger and interval defined
• Evidence of what happens when a check returns an adverse result, including the decision and who took it

• Contractors, temporary staff and outsourced personnel screened by their employer with no verification the check was performed to the required level
• Screening performed once at hire, with no rescreening for people who later move into privileged roles
• Proportionality claimed but not documented, so every role receives the same minimal check regardless of access
• Access granted before screening completes, with no record of the interim risk decision

Requires employment contractual agreements to state what the individual and the organisation are each responsible for with respect to information security.

• Employment contracts and contractor agreements containing the information security responsibilities of both parties
• Evidence the clauses cover confidentiality, acceptable use, return of assets and obligations continuing after employment
• Signed acceptance records for personnel in scope, including those who joined before the current clause set
• Equivalent terms for non employees with access, such as contractors, temporary staff and volunteers
• Evidence of update where responsibilities changed, and communication of the change

• Current contract template compliant while long serving employees remain on terms containing nothing about information security
• Agency and outsourced personnel covered by a contract between the organisation and the agency, with nothing binding the individual
• Terms reference a policy by name that the individual is never given
• No record of signature, so acceptance cannot be evidenced when it is needed

Requires personnel and relevant interested parties to receive appropriate information security awareness, education and training, plus regular updates on the security policy, topic specific policies and procedures relevant to their job function. Supporting SME guidance separates merely informing people from making them aware and from training those holding specific roles, and treats repetition as necessary because objectives, threats and available measures keep changing.

• The awareness and training programme, distinguishing general awareness from role specific training for those with defined security duties
• Completion records per individual, with coverage measured against the full population including contractors
• Content evidence showing the material reflects current policy, current threats and the organisation's own procedures
• Evidence of regular repetition and update rather than a single induction event
• Effectiveness measurement, such as assessment results, phishing simulation trends or observed behaviour change

• Induction training only, with no refresh even though threats and policy have moved
• Completion measured against the employee list, leaving contractors and third party users untrained and uncounted
• Generic purchased content that never mentions the organisation's own procedures or reporting channel
• Effectiveness never measured, so a programme with high completion and no behaviour change looks successful

Requires a formalised disciplinary process, communicated in advance, so that action can be taken where personnel or other relevant parties have breached information security policy.

• The formalised disciplinary process covering information security breaches, and evidence it was communicated in advance
• Evidence of the link from incident and compliance findings into the disciplinary route, including who decides to invoke it
• Records of cases where the process was invoked, with the assessment of the breach and the outcome
• Evidence of consistency, showing similar breaches treated similarly regardless of seniority
• Provisions for non employees, since a disciplinary process does not apply to a contractor

• Process exists in the human resources handbook but was never communicated as applying to security breaches
• No trigger from the incident process, so identified breaches never reach a disciplinary decision
• Senior staff breaches handled informally while junior staff breaches are formalised
• Nothing equivalent defined for contractors and third parties, so there is no consequence at all

Requires the security duties and responsibilities that survive the end of employment, or a move to a different role, to be defined, communicated to the people concerned and enforced.

• Documented responsibilities that remain in force after employment ends or after a change of role, such as confidentiality and non disclosure
• Evidence these were communicated to the individual at the point of departure or change, with acknowledgement
• The leaver and mover procedure showing the security steps and their completion within a defined timeframe
• Records of access removal or adjustment on role change, showing old entitlements withdrawn
• Evidence covering contractors and third party personnel on the same basis

• Exit process removes access without ever restating the obligations that continue
• Movers treated as neither joiner nor leaver, so entitlements accumulate across a career
• Departure known to the manager days before human resources and access removal is triggered from the later date
• Continuing obligations documented but unenforceable because nothing was signed

Requires confidentiality or non-disclosure agreements matching the organisation's need to protect information to be identified, documented, reviewed on a regular basis and signed by personnel and by other relevant parties.

• The confidentiality or non disclosure agreements in use, and the assessment showing they reflect the organisation's protection needs
• Signed agreements for personnel and for third parties with access, held and retrievable
• Evidence of regular review of the agreement terms and of who is covered
• Records of the duration of the obligation and of what happens on termination
• Evidence agreements are in place before access is granted, not afterwards

• Agreements signed at onboarding and never reviewed as the business or the information changed
• Coverage gaps for contractors, interns, auditors and visitors who nonetheless see confidential information
• Signed copies unretrievable, so the obligation cannot be evidenced when it must be enforced
• Obligation expiring at termination of employment, leaving no protection at the point of highest risk

Requires security measures to be implemented when personnel work remotely, protecting information that is accessed, processed or stored outside the organisation's premises.

• The remote working rules, covering approval, permitted locations, equipment, network use and handling of physical material
• Technical measures evidence, such as device encryption, endpoint protection, secure remote access configuration and enforced patching for remote devices
• Evidence of protection where personally owned devices are used, including separation of organisational information
• Guidance and evidence on the physical environment, covering screen visibility, secure storage of documents and use of public spaces
• Records of approval for remote working arrangements and of review of them

• Rules assume the corporate laptop while personally owned devices access the same information under no measure
• Remote access secured while physical aspects such as printing at home and visibility of screens are unaddressed
• Devices that rarely connect to the corporate network drifting out of patch and configuration compliance unnoticed
• Working from other countries permitted informally with no assessment of the legal and data transfer consequences

Requires a mechanism through which personnel can report security events they have observed or suspect, using appropriate channels and without delay.

• The defined reporting mechanism and channels, and evidence they are known to personnel and to relevant third parties
• Reporting records for the period, showing volume, source and the time between observation and report
• Evidence the channel is available at all times and does not depend on a system that may itself be affected
• Evidence of feedback to reporters, which is what sustains reporting rates
• Awareness material showing what people are expected to report, including suspicions and near misses

• Reporting route is the service desk, which is closed when most events occur
• Reporting rates near zero and read as good news rather than as a broken channel
• No feedback to reporters, so people stop reporting after the first ignored report
• Fear of blame suppressing reports, with no evidence of a no blame position being stated or honoured

Requires security perimeters to be defined and used to protect any area holding information and the assets associated with it.

• Definition of the security perimeters, with site plans or drawings showing the boundary of each area holding information and associated assets
• The basis for each perimeter, tied to the classification and criticality of what it protects
• Evidence the perimeter is physically sound, covering walls, doors, windows, roof and floor voids
• Records of inspection or testing of perimeter integrity
• Evidence covering shared and multi tenant buildings, including the boundary between the organisation and other occupants

• Perimeter defined at the building line only, with no internal perimeter around the areas that actually hold sensitive assets
• Fire escapes, service risers, delivery bays and false ceilings bypassing the documented perimeter
• Shared building risks unassessed, so a neighbouring tenant's space adjoins a secure area
• Perimeter documented at design and never re inspected as the building was altered

Requires storage media to be managed across their whole life cycle, covering acquisition, use, transportation and disposal, in accordance with the organisation's classification scheme and handling requirements. Older source material adds that disposal should follow formal procedures scaled to the sensitivity of the information held, and that media in transit needs protection against unauthorised access, misuse and corruption.

• Procedures covering media across acquisition, use, transportation and disposal, tied to the classification scheme
• The media register or tracking record for removable and archival media, showing location and content classification
• Evidence of protection in transit, including packaging, carrier selection and receipt confirmation
• Disposal records showing the method used per media type and per classification, with certificates where destruction was outsourced
• Evidence of technical controls over removable media use, such as port restriction and enforced encryption

• Disposal certificates accepted from a contractor with no serial level reconciliation to what was sent
• Backup and archive media outside the register, so nobody knows what exists or where
• Encryption not applied to removable media, so a lost item is an unbounded exposure
• Media reused across classification levels with no sanitisation between uses

Requires information processing facilities to be shielded from power loss and from other disruption arising when supporting utilities fail.

• Identification of the supporting utilities each information processing facility depends on, covering power, cooling, water, telecommunications and ventilation
• The protective arrangements, such as uninterruptible power supply, generator, redundant feeds and cooling redundancy, matched to the availability requirement
• Testing records demonstrating the arrangements work under load, including full transfer tests not just idle starts
• Maintenance and inspection records including fuel supply, battery condition and contract cover
• Alarm and monitoring evidence for utility failure, and the response procedure

• Generators started monthly without load, so failure under real demand is untested
• Battery capacity assumed at nameplate with no measurement of actual remaining runtime
• Cooling excluded from resilience planning even though its failure takes the facility out fastest
• Fuel contracts in place with no priority guarantee, which matters in a regional event

Requires cables carrying power, data or supporting information services to be protected from interception, interference and damage. Older source material adds routing power and telecommunications lines underground or otherwise protecting them, segregating power cables from communications cables, marking cables clearly to avoid patching errors, and controlling access to patch panels and cable rooms.

• Cable routing documentation showing power and telecommunications routes and any protection applied
• Evidence of segregation between power and communications cabling to avoid interference
• Cable and patch panel labelling standards and evidence of their application
• Access controls over patch panels, cable rooms and risers, and records of who holds access
• Inspection records checking for unauthorised additions, taps or undocumented connections

• Patch rooms unlocked or holding a key kept above the door frame, defeating the whole control
• Labelling absent or wrong, so patching errors cross security zones without anyone realising
• Cabling documentation frozen at build with years of undocumented changes since
• No inspection, so an unauthorised device or tap in a comms room could sit indefinitely

Requires equipment to be maintained correctly, so that information stays available, intact and confidential.

• The maintenance schedule per equipment type, aligned to supplier recommendation and to criticality
• Maintenance records for the period, showing what was done, by whom and when
• Controls over maintenance personnel, including authorisation, supervision and escorting where they access secure areas
• Evidence of protection where equipment is sent off site for repair, including removal or sanitisation of storage media
• Evidence of checks after maintenance, confirming security configuration was not altered

• Equipment sent for warranty repair with the drive still in it and no confidentiality agreement in place
• Maintenance performed remotely by a supplier with the access path unlogged and unrestricted
• Post maintenance verification absent, so a technician's temporary change becomes permanent
• Maintenance tracked for the data centre while distributed and edge equipment is on no schedule at all

Requires items of equipment containing storage media to be verified before disposal or re-use, confirming that sensitive data and licensed software have been removed or securely overwritten.

• The procedure for disposal and re-use of equipment containing storage media, defining the sanitisation method per media type
• Verification records confirming sensitive data and licensed software were removed or securely overwritten, per item
• Asset register entries showing the transition from in use to sanitised to disposed or reissued
• Certificates of destruction or sanitisation from any third party used, reconciled at item level
• Evidence covering embedded and less obvious storage, such as multifunction printers, network equipment and mobile devices

• Verification claimed at batch level, so no individual item can be shown to have been sanitised
• Multifunction devices, network appliances and telephony equipment disposed of with their internal storage intact
• Overwriting method chosen without regard to media type, so solid state media is not effectively sanitised
• Equipment held pending disposal in an insecure area for months, where the real exposure occurs

Requires secure areas to be protected by appropriate entry controls and by control over the access points themselves.

• Entry control configuration for each secure area, showing the authentication required and any multi factor or dual control
• The authorisation list per area, with the basis for each person's access
• Access logs for the period, retained and reviewed, with evidence of what the review looked for
• Visitor procedures, covering identification, authorisation, escort and record of entry and exit
• Evidence of periodic review and removal of physical access rights, including on departure and role change

• Access rights granted at induction and never reviewed, so leavers retain a working badge
• Tailgating unaddressed by both design and monitoring, defeating the entry control entirely
• Visitor logs kept but never reviewed, and visitors unescorted once inside
• Access logs available from the system but never analysed, so anomalous entry goes unnoticed

Requires physical security for offices, rooms and facilities to be designed and then actually implemented.

• Design documentation for the physical security of offices, rooms and facilities, showing the measures selected against the risk
• Evidence of implementation, such as inspection records, photographs or commissioning records for locks, barriers and controls
• Evidence of discretion, such as the absence of signage identifying sensitive facilities and directories not disclosing their location
• Records of key and lock management, including issue, return and rekeying
• Evidence the design is reviewed after changes to layout, occupancy or use

• Measures designed on paper with no verification that what was built matches the design
• Signage, reception directories and public information identifying the location of sensitive facilities
• Key management informal, with unaccounted physical keys and no rekeying after loss
• Changes of use, such as a meeting room becoming a work area for sensitive material, never reassessed

Requires premises to be monitored continuously for unauthorised physical access. Supporting material frames this as continuous monitoring of physical security controls so that unauthorised entry and other physical security incidents are detected and responded to.

• The design of physical monitoring, covering surveillance, intrusion detection, alarms and guarding, and its coverage against the areas defined
• Evidence monitoring is continuous, including out of hours and during holidays
• Records of alarms and detections in the period, with the response taken and the time to respond
• Maintenance and testing records for detection and surveillance equipment
• Evidence of how monitoring data is protected and retained, including privacy compliance for surveillance

• Cameras installed and recording with nobody watching and no alert on anything
• Detection coverage with blind spots at exactly the low traffic entry points an intruder would use
• Alarms received at a monitoring centre with no tested response procedure or agreed response time
• Recording failures unnoticed for months because equipment health is never checked

Requires designed and implemented protection against physical and environmental threats. These include natural disasters as well as other physical threats to infrastructure, whether deliberate or accidental.

• The assessment of physical and environmental threats relevant to each site, covering natural hazards and deliberate and accidental threats
• The protective measures selected against that assessment, such as fire detection and suppression, water detection, and protection against extreme weather
• Testing and maintenance records for protective systems, including fire suppression and detection
• Evidence of siting decisions taking hazard exposure into account, such as flood risk and proximity to hazardous neighbours
• Records of insurance, drills and response arrangements for the identified threats

• Threat assessment generic rather than site specific, so local flood or seismic exposure was never considered
• Fire suppression maintained while water ingress, which is more common in practice, has no detection at all
• Protective systems installed and never tested, so failure is discovered during the event
• New sites and offices brought into use with no assessment inherited or performed

Requires security measures governing how people work inside secure areas to be designed and implemented.

• The rules governing work inside secure areas, covering supervision, recording devices, unattended work and knowledge of the area's existence
• Evidence the rules were communicated to those permitted to work there, including third party personnel and maintenance staff
• Evidence of enforcement, such as inspection, monitoring or spot checks
• Records of third party work in secure areas, showing authorisation and supervision
• Evidence covering unoccupied secure areas, which should be locked and periodically checked

• Rules published with no supervision or check that they are followed
• Photography and recording devices prohibited in policy while every person carries a phone and nothing addresses it
• Maintenance and cleaning staff working unsupervised in secure areas outside working hours
• Vacant secure areas left unlocked because the last person out has no defined responsibility

Requires defined and enforced rules for clearing papers and removable storage media from desks, and for clearing the screens of facilities used to process information.

• The clear desk and clear screen rules, defining what must be cleared and to what standard
• Technical enforcement evidence for screens, such as enforced screen lock timeout configuration across the estate
• Evidence of physical checks or sweeps, with findings and follow up
• Provision of secure storage sufficient for people to comply, such as lockable storage at each workstation
• Evidence covering shared spaces, home working and printing, including collection at the printer

• Rules issued with no secure storage provided, making compliance impossible
• Screen lock configured on corporate laptops while shared terminals, kiosks and operational consoles are excluded
• Printed output left uncollected at shared printers, which is the most commonly observed failure
• No checks performed, so compliance is asserted from the existence of the policy

Requires equipment to be sited securely and protected. Older source material in the folder expands this as siting equipment to reduce unnecessary access into work areas, positioning and restricting the viewing angle of facilities handling sensitive data, isolating items needing special protection, and guarding against physical hazards such as theft, fire, water, dust, vibration, electrical interference and vandalism.

• Siting records or floor plans showing equipment placement and the reasoning, including restriction of unnecessary access to work areas
• Evidence of viewing angle and screen positioning control where sensitive information is displayed
• Evidence of isolation for items needing special protection, and of protection against hazards such as fire, water, dust, vibration and electrical interference
• Environmental monitoring records for areas holding sensitive equipment
• Rules on eating, drinking and smoking near equipment, and evidence of their enforcement

• Screens in reception areas, open plan seating and meeting rooms visible to visitors and to windows
• Equipment relocated during office churn with no reassessment of the original siting decision
• Environmental hazards such as water pipes above equipment rooms never identified
• Protection assessed for the data centre while the equally sensitive equipment in offices is ignored

Requires assets located away from the organisation's premises to be protected.

• Rules covering assets taken off site, including authorisation, permitted use and the protection required
• Records of assets held off premises, covering laptops, mobile devices, removable media and physical records
• Evidence of protection appropriate to the location, such as encryption, tracking, remote wipe capability and rules for leaving equipment unattended
• Evidence covering assets at home working locations and at third party sites
• Records of loss or theft off site and the response taken

• Register of what is off site does not exist, so exposure after a theft cannot be determined
• Encryption assumed present but never verified as enabled on the specific device
• Rules covering laptops while paper records, backup media and portable storage taken off site are unaddressed
• Loss reporting slow or absent because there is no clear route and people fear blame

• Control implementation
• Control evidence
• Control attributes

• Controls inherited from a previous edition (2013) not refreshed against the 2022 attribute model.
• Detective controls present but corrective actions undocumented when triggered.

• Control implementation
• Control evidence
• Control attributes

• Controls inherited from a previous edition (2013) not refreshed against the 2022 attribute model.
• Detective controls present but corrective actions undocumented when triggered.

• Control implementation
• Control evidence
• Control attributes

• Controls inherited from a previous edition (2013) not refreshed against the 2022 attribute model.
• Detective controls present but corrective actions undocumented when triggered.

Requires information stored on, processed by or accessible through user endpoint devices to be protected.

• The endpoint device policy covering corporate and personally owned devices, registration, permitted use and required protections
• Configuration baselines for each device type and evidence of compliance across the estate, with the percentage of devices compliant
• Evidence of the protective measures in force, such as full disk encryption, endpoint detection, screen lock, patch currency and restriction of administrative rights
• Evidence of separation of organisational information on personally owned devices and of the ability to remove it
• Records of lost or stolen devices and the action taken, including remote wipe evidence

• Compliance reported for devices that check in, silently excluding devices that have not connected for months
• Encryption enabled at build with no ongoing verification that it remains enabled and the recovery key escrowed
• Personally owned devices accessing mail and documents under a policy statement with no technical control behind it
• Local administrator rights retained by users, which undermines every other endpoint control

Requires information held in information systems, devices or any other storage media to be deleted once it is no longer required. Supporting material frames this as procedures for secure deletion at the point the information ceases to be needed.

• Deletion rules tied to retention requirements, per information type and per system
• Evidence of deletion actually performed, such as job records, deletion logs or reports of records removed
• The method used for each medium, and evidence it renders the information unrecoverable to the required standard
• Evidence covering copies, including backups, archives, replicas, test environments and third party held data
• Records of deletion requests handled, including data subject erasure requests where privacy law applies

• Deletion performed in the primary system while backups, archives and replicas retain the data for years
• Deletion is a logical flag rather than a removal, leaving the data present and recoverable
• Third party and cloud held copies outside the deletion process entirely
• No verification, so a failed deletion job is indistinguishable from a successful one

Requires data masking to be used in accordance with the topic specific policy on access control, other related topic specific policies and business requirements, taking applicable legislation into account. Supporting material notes the common case of protecting sensitive data used for testing or development.

• The rules on masking, pseudonymisation and anonymisation, tied to the access control policy and to applicable legislation
• Identification of the environments and use cases where masking applies, such as development, testing, training, analytics and support
• Technical evidence of the masking applied, including the technique and evidence it resists re-identification
• Records of exceptions where real data is used outside production, with approval and compensating controls
• Evidence of testing that masked data sets contain no residual identifiable values

• Production data copied to non production with masking applied to obvious fields only, leaving free text and attachments identifiable
• Masking that is reversible or consistent enough to permit re-identification by combination
• Exception process absent, so teams take production copies informally and nobody knows
• Masking implemented once and never re-verified after new fields were added to the schema

Requires data leakage prevention measures across systems, networks and any other device that processes, stores or transmits sensitive information.

• Identification of the sensitive information to be protected and of the channels through which it could leave
• Configuration of the leakage prevention measures per channel, covering email, web and cloud upload, removable media and endpoint
• Evidence of the detection rules used and how they were tuned to the organisation's own data
• Records of detections, the review of them and the action taken, distinguishing blocked from monitored
• Evidence of governance over the monitoring itself, including privacy and legal review

• Tooling deployed in monitor mode indefinitely, generating alerts nobody triages and blocking nothing
• Rules based on generic patterns that miss the organisation's actual sensitive data formats
• Channels covered selectively, so a blocked email route is trivially bypassed by a cloud upload
• Detections closed in bulk, so the tool produces cost and no assurance

Requires backup copies of information, software and systems to be maintained and regularly tested, in line with the agreed topic specific policy on backup. Supporting SME guidance treats regular creation of backups together with tested recovery as the substance of the control, not the copy on its own.

• The backup policy setting scope, frequency, retention and recovery objectives per system
• Backup job records for the period showing successes and failures, and the follow up on failures
• Restoration test records showing actual restores performed, what was restored and whether it met the recovery objective
• Evidence of backup protection, including encryption, access restriction and immutability or offline copies against ransomware
• Evidence the backup scope matches the current environment, reconciled against the asset inventory

• Backup success reported by the job while restoration was never attempted, which is the classic and most damaging gap
• Restore tests performed on a convenient small file rather than on a full system to the stated objective
• Backups reachable from the same credentials and network as production, so ransomware encrypts them too
• New systems never added to the backup scope because nothing reconciles the two lists

Requires information processing facilities to be implemented with redundancy sufficient to meet the availability requirements placed on them.

• Availability requirements per service, expressed as measurable objectives
• The redundancy design showing how each requirement is met, and where single points of failure remain
• Evidence of failover testing, with results measured against the objective and the date of the last test
• Monitoring evidence showing redundant components are healthy and not silently failed
• Records of the residual single points of failure and their formal acceptance

• Redundancy present in the platform while a shared dependency, such as a single directory, database or network path, remains a single point of failure
• Failover never tested in production conditions, so the untested path fails when it is needed
• Redundant components degraded for months without notice because their health is not monitored separately
• Redundancy claimed inside one data centre or region, offering nothing against a site or region event

Requires logs to be produced, stored, protected and analysed, covering activities, exceptions, faults and any other event of relevance. Older source material adds that records of user activity, exceptions and security events should be retained for an agreed period to support later investigation and access control monitoring, and that faults should be logged, analysed and acted on.

• The logging standard, defining what events are logged per system type, including access, privileged action, change and failure
• Evidence of logging enabled, sampled across systems, with the retention period applied
• Evidence logs are protected against alteration and deletion, including restriction of administrator ability to modify them
• Evidence of analysis, showing logs are reviewed or fed to detection rather than merely stored
• Records of gaps in logging identified and remediated, including systems that cannot log to the standard

• Logging enabled with retention shorter than the time it typically takes to discover an incident
• Logs held on the same system they record, so an attacker with control of the host controls the evidence
• Collection achieved and analysis absent, so the organisation pays for storage and receives no detection
• Cloud and software as a service audit logs never enabled because they carry an extra cost or licence tier

Requires networks, systems and applications to be monitored for anomalous behaviour, with appropriate action taken to evaluate whether what is observed constitutes an information security incident. Secondary commentary notes the deliberate shift to anomalous behaviour as the trigger, responding to cloud era risk.

• The monitoring design showing what is monitored across networks, systems and applications, and against which baseline of normal behaviour
• The detection rules or analytics in use, with evidence of how they were derived and their coverage of relevant threat behaviour
• The tuning record, showing rules adjusted over time, false positives reduced and gaps closed
• Alert handling records showing triage, the time to triage, and the evaluation deciding whether the alert was an incident
• Evidence of monitoring coverage over cloud, identity and application layers, not only network and endpoint

• Baseline of normal behaviour never established, so anomaly cannot be defined and only known signatures are caught
• Alert volume beyond what the team can triage, so alerts are closed unexamined and the control is nominal
• Rules deployed at implementation and never tuned, so the same false positives are dismissed daily and a real one is dismissed with them
• Monitoring stops at the perimeter, leaving lateral movement and identity abuse undetected

Requires the clocks of the information processing systems the organisation uses to be synchronised to approved time sources.

• The approved reference time sources and the synchronisation architecture, including the hierarchy of internal servers
• Configuration evidence showing systems synchronise to the approved sources, sampled across platforms
• Monitoring or alerting on synchronisation failure and on drift beyond a defined tolerance
• Evidence covering network devices, appliances, cloud services and containers, not only servers
• Records of time zone handling and of the standard used in log records

• Servers synchronised while network devices, appliances and applications set their own time, so correlation across an incident fails
• Synchronisation configured and never monitored, so a failed source goes unnoticed until timestamps disagree
• Multiple unrelated time sources in use across the estate, producing inconsistent ordering of events
• Local time recorded in logs with no time zone, which makes cross system reconstruction unreliable

Requires the use of utility programs capable of overriding system and application controls to be restricted and tightly controlled.

• Identification of the utility programs capable of overriding system or application controls, per platform
• Evidence of restriction, showing who may use them and how that is enforced, including removal from systems where they are not needed
• Authorisation records for each permitted use, and evidence use is time limited where appropriate
• Logs of utility program use and evidence those logs are reviewed
• Segregation evidence keeping utility use apart from ordinary application use

• Utilities present by default on every build and never removed or restricted
• Use permitted broadly to administrators with no per use authorisation and no review of what was done
• Usage logging absent, so an override of application controls leaves no trace
• Modern equivalents such as scripting frameworks, cloud shells and database clients not recognised as being in scope

Requires procedures and measures to be implemented to manage software installation on operational systems securely. Secondary commentary notes that this replaces a narrower restriction on software installation and is oriented to remote working and mobile devices.

• Procedures governing installation of software on operational systems, including who may install and under what authorisation
• Evidence of technical restriction, such as removal of installation rights, application allow listing or package repository control
• Records of installations performed in the period, tied to an approved change
• Version and rollback control, showing previous versions retained and a documented rollback route
• Evidence covering vendor supplied updates and remote installation by suppliers

• Installation restricted on endpoints while operational servers permit direct installation by administrators outside change control
• Software installed to resolve an incident and never brought back through change or documented
• No rollback capability, so a failed installation becomes an outage
• Supplier remote installation permitted with no record of what was installed or when

Requires the allocation and use of privileged access rights to be restricted and actively managed.

• The definition of what counts as privileged in each system, and the register of privileged accounts and their holders
• Authorisation records for each privileged allocation, showing the business justification and the approver
• Evidence of restriction, such as separate administrative accounts, multi factor authentication, session recording, vaulting or time bound elevation
• Logs of privileged activity and evidence of their review
• Records of periodic review of privileged rights, and of revocation where the need has ended

• Privileged access defined for infrastructure while application, database and cloud console privilege is uncounted
• Administrators using one account for daily work and for administration, so privileged action cannot be isolated
• Privileged activity logged and never reviewed, meaning the compensating control assumed by the design does not exist
• Emergency accounts with permanent standing privilege and no post use review of what they did

Requires networks and network devices to be secured, managed and controlled in order to protect the information carried in systems and applications.

• Network documentation showing the current topology, zones, connections and the security controls at each boundary
• Configuration standards for network devices and evidence of compliance, including management plane protection
• Firewall and access control rule sets, with evidence of periodic review and removal of obsolete or overly permissive rules
• Evidence of authentication and encryption for network device management and for remote administration
• Records of network monitoring and of the response to unauthorised connections or devices

• Rule sets grown by addition over years with no review, containing permissive any to any rules nobody will remove
• Network diagrams out of date, so the actual attack surface differs from the documented one
• Device management interfaces reachable from the general user network
• Cloud networking treated separately and excluded from the network security standard

Requires the security mechanisms for network services, along with their service levels and the requirements placed on them, to be identified, implemented and monitored, whether provision is in house or outsourced.

• Identification of network services in use, whether in house or outsourced, with their owners
• The security mechanisms, service levels and management requirements defined for each service
• Evidence of implementation of those mechanisms, such as encryption, authentication and connection controls
• Monitoring evidence showing service levels and security requirements are actually being met
• Agreements with network service providers containing the security requirements, and evidence of assurance obtained

• Requirements defined for internal services while carrier and internet provider services carry only commercial terms
• Service levels monitored for availability while the security requirements attached to them are never verified
• Assurance from providers accepted as a certificate with no check that the purchased service is in scope
• Legacy circuits and connections still live with no owner and no defined requirement

Requires segregation within the organisation's networks, keeping groups of information services, of users and of systems apart from one another.

• The segregation design, showing the defined zones and the criteria placing systems, services and users into each
• Enforcement evidence at each boundary, such as firewall rules, access control lists or micro segmentation policy
• Evidence of segregation for wireless, guest, third party, management and operational technology networks
• Testing evidence confirming the segregation holds, such as segmentation testing results
• Records of exceptions crossing zone boundaries, with approval and review

• Segregation designed and undermined by broad permit rules between zones that were added for a project and never removed
• Management networks flat and reachable, which converts a single compromise into full estate access
• Segregation never tested, so the design and the enforced reality are unverified
• Guest and third party access bridged into internal segments by shared infrastructure

Requires access to external websites to be managed so as to reduce exposure to malicious content.

• The web filtering policy defining the categories blocked and the basis for blocking
• Configuration evidence showing the filtering in force, including its coverage across office, remote and mobile users
• Evidence of handling encrypted traffic, and any decisions taken about inspection, with the privacy considerations
• Records of exceptions and of the approval and review of them
• Reporting on blocks and on attempted access to malicious sites, with follow up on repeated attempts

• Filtering enforced on the corporate network only, so a remote user is unfiltered
• No control over bypass routes such as personal devices, tethering and virtual private network services
• Category lists left at defaults, blocking productivity categories while permitting newly registered and uncategorised domains that carry the actual risk
• Reports produced and never reviewed, so repeated malicious access attempts from one host are missed

Requires defined and implemented rules on using cryptography effectively, including how cryptographic keys are managed.

• The cryptography rules, defining approved algorithms, key lengths and protocols, and where cryptography must be used
• Evidence of implementation, sampled across data at rest, data in transit and any application layer encryption
• The key management procedures covering generation, distribution, storage, rotation, revocation, archival and destruction
• Evidence of key protection, such as hardware security modules or a managed key service, with access controls and dual control where warranted
• Records of periodic review against current cryptographic guidance, and a plan for deprecating weak algorithms

• Rules defined while deprecated protocols and cipher suites remain enabled on live services
• Key management undocumented, so nobody can say where a key is held, who can use it or when it was last rotated
• Rotation never performed because the process was never built, so keys are effectively permanent
• Encryption claimed from a cloud service default with no control over, or knowledge of, key custody

Requires rules covering the secure development of both software and systems to be established and applied.

• The secure development rules covering the full lifecycle, from requirements through design, build, test and release
• Evidence the rules apply to all development, including agile teams, integration work and vendor delivered code
• Evidence of security activities at each stage, such as threat modelling, secure design review, code review and security testing
• Records of developer security competence and training
• Evidence of enforcement, such as pipeline gates that stop a release failing a security requirement

• Rules written for a delivery model no team uses, so they are ignored in practice
• Security activities defined as recommended rather than required, so they are the first thing dropped under deadline
• Contractor and vendor written code exempt from the rules that internal code must meet
• No gate, so the process depends entirely on individual discipline

Requires information security requirements to be identified, specified and approved when applications are being developed or acquired.

• The method for identifying security requirements for applications, whether developed or acquired
• Documented and approved security requirements for applications delivered in the period, covering authentication, authorisation, data protection, logging and error handling
• Evidence requirements were derived from risk, from the data classification and from applicable legal obligations
• Evidence of verification that delivered applications meet the approved requirements
• Evidence covering acquired and software as a service applications, where requirements become procurement and configuration criteria

• Requirements written generically and copied between projects, so none reflect the actual data or threat
• Acquired software exempted, so most of the application estate has no security requirements at all
• Requirements approved and never verified against the delivered product
• Transaction level requirements such as integrity, non repudiation and audit trail omitted entirely

Requires principles for engineering secure systems to be established, documented and maintained, then applied across all information system development work.

• The documented secure engineering principles, such as defence in depth, least privilege, secure defaults, fail secure and minimising trust
• Evidence of maintenance, showing the principles are reviewed against current technology and threat
• Design documentation for systems delivered in the period showing the principles were applied
• Architecture review records, showing who reviewed and what was decided, including deviations accepted
• Evidence the principles apply across all development work, including infrastructure as code and cloud architecture

• Principles stated at a level so abstract that no design decision can be tested against them
• Architecture review applied to large projects only, so incremental change accumulates unreviewed
• Principles authored once and never revised, so they do not address cloud, containers or identity centred architecture
• Deviations accepted informally with no record, so the exception becomes the pattern

Requires secure coding principles to be applied to software development.

• The secure coding standard in use, per language and framework, and evidence it was communicated to developers
• Evidence of application, such as static analysis configuration and results, peer review records and the treatment of findings
• Evidence of control over third party and open source components, including inventory, known vulnerability checking and update process
• Records of developer training in secure coding relevant to the languages actually used
• Evidence of the treatment of findings, showing severity thresholds that block a release

• Standard adopted from a generic source with no mapping to the languages and frameworks in use
• Static analysis running with findings suppressed or accumulating in a backlog nobody triages
• Third party components inventoried at first use and never rechecked as vulnerabilities are published against them
• Review evidence showing approval within seconds of submission, which demonstrates the review was nominal

Requires security testing processes to be defined and implemented within the development life cycle.

• The security testing process defining what testing is performed at which stage, and the acceptance criteria
• Test results for the period, covering the techniques used such as static analysis, dynamic testing, dependency scanning and penetration testing
• Evidence testing occurs in the development lifecycle and again at acceptance, rather than only before a major release
• Records of findings, their severity, remediation and retest evidence
• Evidence of the independence and competence of testers where the testing is meant to be independent

• Testing performed once a year against a production system, with everything released between times untested
• Findings recorded with no retest, so remediation is assumed rather than confirmed
• Acceptance criteria absent, so a release proceeds with open high severity findings and no decision record
• Test scope excludes the components most likely to be attacked, such as application programming interfaces and administrative interfaces

Requires access to information and other associated assets to be restricted in accordance with the established topic specific policy on access control.

• Evidence access to information is restricted per the access control policy, sampled at the system and data level rather than only at the network level
• Configuration of the restriction mechanisms, such as application roles, database permissions, file share permissions and cloud storage policies
• Evidence of restriction on functions as well as data, including read against write against delete and export
• Evidence of controls over dynamic access such as reporting tools and direct query access
• Records of testing that the restriction actually holds, such as access testing results

• Access controlled at the application while the underlying database or storage is broadly readable, bypassing the whole model
• Reporting and analytics platforms replicating data into an environment with weaker restriction
• Export and download functions unrestricted, so read access is effectively copy access
• Restriction configured once and never tested, so a permission drift goes unnoticed

Requires the organisation to direct, monitor and review the activities involved in outsourced system development. Secondary commentary notes that explicit direction and review were added in the 2022 revision in response to third party risk.

• Contractual security requirements imposed on the development supplier, covering secure development practice, testing, code ownership and the right to review
• Evidence of direction given, such as agreed standards, architecture constraints and acceptance criteria
• Evidence of monitoring during delivery, including progress and security reviews rather than acceptance testing alone
• Review evidence of the delivered code and its components, including independent testing
• Records of the handling of intellectual property, escrow and access to the code after delivery

• Requirements set in the contract with no monitoring during delivery, so the first check is at acceptance
• Supplier assurance accepted as their own test results with nothing independent
• Code delivered as a binary with no visibility of components or practice
• Subcontracted development by the supplier not disclosed or covered by any equivalent requirement

Requires development, testing and production environments to be separated from one another and each of them secured.

• Documentation of the environments in use and the separation between them, covering network, credential, data and administrative separation
• Evidence of technical enforcement, such as separate accounts, subscriptions or tenancies and distinct credentials per environment
• Controls over promotion between environments, showing what is required to move code to production
• Evidence of control over data placed in non production environments, tied to the masking requirement
• Evidence developers do not hold standing production access, or that such access is controlled and logged where required

• Environments logically separated while sharing credentials, directory, keys or a management plane
• Production data copied to test as a matter of routine, which makes the test environment a production exposure with weaker controls
• Developers holding standing production access for support, defeating the separation entirely
• Non production environments unpatched and unmonitored while connected to the same network as production

Requires change management procedures to govern changes made to information systems and to the facilities that process information. Older source material adds that changes should be controlled by formal, documented and enforced procedures, with risk assessed as part of the process.

• The change management procedure covering the types of change, the authorisation required and the route for emergency change
• Change records for the period, showing risk and security impact assessment, testing evidence, approval and implementation record
• Evidence of segregation between the person requesting, approving and implementing a change
• Rollback plans and evidence they are viable, plus post implementation review records
• Evidence of detection of unauthorised change, reconciling changes made against changes approved

• Emergency change route used routinely to avoid the standard process, with retrospective approval that is never refused
• Security impact assessment reduced to a checkbox with no analysis behind it
• No reconciliation between changes made and changes approved, so unauthorised change is undetectable
• Approver and implementer the same person, so approval carries no independent judgement

Requires test information to be appropriately selected, protected and managed.

• Rules on selecting test information, showing preference for synthetic or masked data over production copies
• Authorisation records where production information is used for testing, including who approved and for how long
• Evidence of protection of test information equivalent to its classification, including access control and deletion after use
• Records of the test data lifecycle, showing creation, use and removal
• Logging of access to test environments holding sensitive information

• Production copies taken to test with approval never sought and removal never performed, so the copy persists for years
• Test environments open to a wider audience than production while holding the same data
• Test data protection assumed lower because the environment is called test, which is exactly backwards once real data is present
• No inventory of which test environments hold production derived data

Requires audit tests and other assurance activities that assess operational systems to be planned and agreed in advance between the tester and the appropriate management.

• The procedure requiring audit and assurance tests on operational systems to be planned and agreed with appropriate management in advance
• Agreements for tests performed in the period, showing scope, timing, method, access granted and the limits placed on the tester
• Evidence of read only access where feasible, and of controls where the test required more than read access
• Logging and monitoring of the tester's activity, and evidence access was revoked at the end
• Records of any operational impact caused by testing and the handling of it

• Testing agreed verbally with no scope document, so the tester and the system owner disagree about what was permitted
• Auditor accounts created with broad access and never removed after the engagement
• Automated scanning run against production with no agreement, causing outage of the system it was meant to assure
• Tester activity unlogged, so the actions taken during the test cannot be separated from anything else that happened

Requires managed control over who can read and who can write to source code, and equally over development tools and software libraries.

• Access controls over source code repositories, showing read and write permissions and who holds them
• Controls over development tools, libraries and build systems, including who can alter build configuration
• Evidence of branch protection, mandatory review and restriction on direct commits to protected branches
• Records of periodic review of repository access, including external collaborators and service accounts
• Evidence of secrets management, showing credentials are not held in source code, with scanning evidence

• Write access broadly granted across the engineering organisation with no per repository restriction
• Credentials, keys and tokens committed to repositories, present in history even after removal from the current version
• Build systems and pipelines able to be modified by anyone who can commit, which bypasses code review entirely
• Access reviews covering people while service accounts, integrations and deploy keys are never reviewed

Requires secure authentication technologies and procedures to be implemented, driven by the information access restrictions and the topic specific policy on access control.

• The authentication standard, setting required methods against the sensitivity of the information and the access route
• Configuration evidence per system showing the enforced authentication, including multi factor coverage and the factors accepted
• Evidence of protection against brute force and credential stuffing, such as lockout, rate limiting and anomaly detection
• Session management configuration, covering timeout, re-authentication for sensitive actions and secure token handling
• Records of exceptions where the standard is not met, with approval and compensating measures

• Multi factor authentication enforced for the corporate identity provider while legacy protocols and direct application logins bypass it
• Exceptions granted for convenience to senior or technical staff, which are the accounts most worth attacking
• Service and machine accounts excluded with no compensating restriction on where they can authenticate from
• Coverage claimed at the platform level with no per application verification

Requires resource consumption to be monitored, and capacity to be adjusted so it matches both current demand and what is expected.

• Monitoring evidence for resource consumption across compute, storage, network, licence and, where relevant, personnel capacity
• Defined thresholds and alerting on approaching capacity limits
• Capacity forecasts based on trend and on planned business change, with the review cycle
• Records of capacity being adjusted as a result, showing the control produces action
• Evidence capacity is considered for security functions too, such as log storage and detection processing

• Monitoring in place with no thresholds, so consumption is visible only after the outage
• Forecasting based on historical trend alone, ignoring known business change such as a product launch or acquisition
• Log and monitoring storage overflowing, silently dropping the security evidence the organisation depends on
• Cloud capacity assumed elastic, ignoring quota limits and cost controls that behave exactly like capacity limits

Requires malware protection to be put in place and reinforced by suitable awareness among users.

• Malware protection deployment records showing coverage across servers, endpoints, mobile devices, email and web gateways
• Configuration evidence including update frequency, scanning scope, real time protection and the action taken on detection
• Coverage reporting showing devices without protection or with outdated definitions, and the follow up on them
• Detection records for the period and the response taken to each
• Awareness evidence covering user recognition and reporting of malicious content

• Coverage measured only across managed devices, so the unmanaged remainder is invisible
• Alerts generated and closed automatically with no analysis of repeat detections on the same host
• Protection disabled on servers or on specific paths for performance, with exclusions never reviewed
• Awareness treated as covering the control, with no technical prevention behind it

Requires information about technical vulnerabilities in the information systems in use to be obtained, the organisation's exposure to them to be evaluated, and appropriate measures to be taken. Older source material sets out the surrounding process: named roles and responsibilities, identified information sources, a defined reaction timeline, assessment of the risk posed by the vulnerability against the risk of applying the patch, testing before deployment, alternative measures where no patch exists, an audit log of actions taken, and highest risk systems addressed first.

• Defined roles and information sources for vulnerability identification, and the asset scope they cover
• Scan results and vulnerability inventory for the period, with authenticated scanning where applicable
• The defined reaction timeline by severity, and measurement of actual remediation against it
• Risk assessment records weighing the vulnerability against the risk of applying the patch, and evidence of testing before deployment
• Records of alternative measures where no patch exists, and the audit log of actions taken

• Scanning covers the network perimeter and misses internal, cloud, container and application layer exposure
• Remediation timelines defined and routinely breached, with no exception or risk acceptance record
• Unauthenticated scanning only, which understates exposure substantially
• Highest risk systems not prioritised, so remediation follows whatever is easiest to patch

Requires configurations of hardware, software, services and networks, including their security configurations, to be established, documented, implemented, monitored and reviewed. Supporting material frames this as a standing process that keeps systems configured securely and consistently.

• Documented secure configuration baselines per platform and service, and their basis such as a recognised benchmark
• Evidence baselines are implemented, sampled across live systems rather than assumed from the build image
• Automated compliance monitoring output showing conformance and drift, with the frequency of measurement
• Records of exceptions to baseline, with justification, approval and expiry
• Change control over the baselines themselves, showing review as platforms and threats change

• Baseline applied at build with no ongoing measurement, so configuration drifts unchecked from day one
• Exceptions accumulating with no expiry, until the exception list describes the actual estate
• Cloud and container configuration excluded because the baseline concept was defined for servers
• Monitoring detects drift and generates no action, so the finding recurs every cycle

• Control implementation
• Control evidence
• Control attributes

• Controls inherited from a previous edition (2013) not refreshed against the 2022 attribute model.
• Detective controls present but corrective actions undocumented when triggered.

• Control implementation
• Control evidence
• Control attributes

• Controls inherited from a previous edition (2013) not refreshed against the 2022 attribute model.
• Detective controls present but corrective actions undocumented when triggered.