Annex A: all 93 controls

1. Your information security policy, signed off by senior management and dated.
2. Your other security policies (for example access control, backup, acceptable use), each with an owner, version number and next review date.
3. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.1 marked as used or not used, a short reason, and its current status.
4. Proof that staff have read and accepted the policies, such as sign-off records or acknowledgements.
5. Evidence that each policy was reviewed on schedule, such as a review date and change notes.
6. Where staff can find the policies, such as an intranet page or onboarding pack.
7. Staff should be able to tell you where the policies live and name a few rules that apply to their job.

Information Security Policy and topic-specific policies

1. A document listing the security roles in your organization and what each person is responsible for.
2. Job descriptions for key roles that mention their security duties.
3. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.2 marked as used or not used, a short reason, and its current status.
4. An up-to-date organization chart showing who holds each security role.
5. Proof people accepted their roles, such as an appointment email or meeting notes.
6. Each person in a security role should be able to explain what they are responsible for.

1. Information Security Roles and Responsibility Policy
2. ISMS roles, responsibilities and authorities document
3. Risk Management Policy

1. Your access control policy, stating that conflicting tasks are split between different people (segregation of duties).
2. A simple table showing which tasks must not be done by the same person, such as requesting and approving a payment.
3. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.3 marked as used or not used, a short reason, and its current status.
4. A few recent payments, changes or user setups showing one person asked and a different person approved.
5. A list of who has access to sensitive processes, showing no one person can do everything alone.
6. Be able to show how your systems stop someone from approving their own request.

Human Resource Security Policy

1. Your information security policy with a clear statement that management expects everyone to follow it.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.4 marked as used or not used, a short reason, and its current status.
3. Management messages or meeting notes reminding staff about security.
4. Training completion records showing managers make sure their teams finish required training.
5. Staff objectives or reviews that include security expectations, where you use them.
6. Managers should be able to explain how they encourage and check good security habits in their team.

1. Human Resource Security Policy
2. Information Security Policy
3. Information Security Roles and Responsibilities Policy

1. A contact list for the authorities you may need to reach (police, regulators, the data protection authority), with phone numbers and email addresses.
2. A short note on when you must contact them, such as reporting a data breach within a set time.
3. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.5 marked as used or not used, a short reason, and its current status.
4. Proof the contact list was checked recently.
5. Records of any contact made with authorities during incidents.
6. Be able to say who is responsible for contacting the authorities and when.

Incident Response Plan

1. A list of security groups, forums or professional bodies your organization belongs to or follows.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.6 marked as used or not used, a short reason, and its current status.
3. Membership confirmations, newsletter subscriptions or event attendance records.
4. An example of useful information from these groups that was shared or acted on.
5. Be able to explain how information from these groups is used.

1. Human Resource Security Policy
2. Information Security Roles and Responsibilities Policy

1. A short procedure for threat intelligence (information about current threats): which sources you use, who reviews them and what happens next.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.7 marked as used or not used, a short reason, and its current status.
3. Examples of threat information received, such as national security advisories or supplier security notices.
4. A few examples showing a threat was checked for relevance and any action was tracked to completion.
5. Updates to your risk register prompted by new threats.
6. Be able to explain how you decide whether a threat matters to you.

1. Operations Security Policy
2. Information Security Roles and Responsibilities Policy

1. Your project process or templates showing security is considered at the start, during and before go-live.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.8 marked as used or not used, a short reason, and its current status.
3. One or two recent projects with a completed security risk check or security requirements.
4. Go-live sign-offs showing security actions were completed.
5. A project manager should be able to explain how security is built into projects.

Risk Management Policy

1. Your asset management policy.
2. Your asset inventory: a list of your information, devices, software and services, each with an owner.
3. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.9 marked as used or not used, a short reason, and its current status.
4. Proof the inventory was reviewed and updated recently.
5. Evidence that new assets are added and old ones removed, such as recent entries for new laptops and disposed equipment.
6. A spot check showing items on the list really exist, and items in use are on the list.
7. Be able to show how a new device or system gets added to the inventory.

Asset Management Policy

1. Your acceptable use policy: the rules for using company information and equipment.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.10 marked as used or not used, a short reason, and its current status.
3. Proof that staff and contractors have accepted the rules.
4. Records of any misuse cases and how they were dealt with.
5. A list of managed devices or accounts showing equipment is used as the rules say.
6. Staff should be able to name a few key rules, such as not sharing passwords.

1. Asset Management Policy
2. Data Management Policy
3. Information Security Policy

1. Your leaver checklist, including returning equipment and access cards.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.11 marked as used or not used, a short reason, and its current status.
3. A list of people who left in the last 12 months, with proof their equipment was returned.
4. Follow-up records for anything not returned, such as remotely locking a laptop.
5. Be able to explain who checks that items are returned and how.

1. Asset Management Policy
2. Human Resource Security Policy
3. Information Security Policy

1. Your classification policy: the levels you use (for example Public, Internal, Confidential) and what goes in each.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.12 marked as used or not used, a short reason, and its current status.
3. Examples of information with its classification recorded, such as in the asset inventory.
4. Proof classifications are reviewed from time to time.
5. Staff should be able to explain the levels and give an example of each.

Data Management Policy

1. Simple instructions on how to label information at each classification level (paper, documents, email).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.13 marked as used or not used, a short reason, and its current status.
3. Examples of labelled documents, reports or shared folders.
4. Examples of labelled printed or removable media where relevant.
5. Be able to show labelling in everyday use, such as a 'Confidential' footer.

Data Management Policy

1. Your information transfer policy: approved ways to share information by email, file sharing, post and phone.
2. Agreements with partners you regularly exchange data with, including security terms.
3. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.14 marked as used or not used, a short reason, and its current status.
4. A few recent examples of confidential data sent outside the company using an approved, protected method.
5. Courier or tracked delivery records for physical media, if used.
6. Be able to show how you send a confidential file to a customer or supplier.

Third-Party Management Policy

1. Your access control policy, showing who is allowed to access what, based on 'only what you need for your job'.
2. A role-based access table showing standard access for each job.
3. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.15 marked as used or not used, a short reason, and its current status.
4. A list of users and their access for key systems, matching their roles.
5. Approval records for recent access requests.
6. Be able to walk through how someone requests and gets access.

1. Access Control Policy
2. Physical Security Policy

1. Your process for creating, changing and removing user accounts.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.16 marked as used or not used, a short reason, and its current status.
3. A full user list showing everyone has their own account.
4. A list of shared or system accounts, each with a named owner and reason.
5. Examples of recent joiners and leavers showing accounts were created and removed correctly.
6. Be able to explain how accounts are kept in step with HR changes.

Access Control Policy

1. Your password and login policy, including multi-factor authentication (a second step like a code or app approval).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.17 marked as used or not used, a short reason, and its current status.
3. Screenshots or exports of system settings showing password and multi-factor rules are switched on.
4. Proof that new users must change their first password.
5. Staff acknowledgement that they must keep passwords secret.
6. Be able to show multi-factor login on your most important systems.

1. Access Control Policy
2. Information Security Policy

1. Your process for giving, changing, reviewing and removing access.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.18 marked as used or not used, a short reason, and its current status.
3. A list of everyone who has left in the last 12 months and proof their access was removed on time.
4. A list of new starters and proof their access was approved and matched their role.
5. Records of your regular access reviews (who checked what, and what was changed).
6. Examples of people who changed role, showing old access was removed.
7. Be able to explain how managers check access during reviews.

Access Control Policy

1. Your supplier security policy: how you check suppliers before using them.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.19 marked as used or not used, a short reason, and its current status.
3. Your supplier list, marked by how important or risky each one is.
4. Completed security checks or questionnaires for your key suppliers.
5. Be able to explain how security is considered when choosing a supplier.

Third-Party Management Policy

1. Your standard contract wording for supplier security.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.20 marked as used or not used, a short reason, and its current status.
3. Signed contracts with key suppliers that include security, confidentiality, breach notification and right-to-audit terms.
4. Data processing agreements where suppliers handle personal data.
5. Be able to explain how security terms are agreed with suppliers.

Third-Party Management Policy

1. Your process for checking technology suppliers, including the suppliers they rely on.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.21 marked as used or not used, a short reason, and its current status.
3. Security checks for key technology suppliers that cover their own subcontractors.
4. Records of being told about, or approving, a supplier's subcontractors.
5. Be able to explain how you judge the risk of new software or services.

Third-Party Management Policy

1. Your process for monitoring suppliers and handling changes.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.22 marked as used or not used, a short reason, and its current status.
3. Notes from regular supplier reviews covering security.
4. Supplier certificates or independent security reports, with notes showing someone read them.
5. Records of checking the security impact when a supplier changed its service.
6. Be able to explain what you do when a supplier falls short.

Third-Party Management Policy

1. Your cloud services policy: how you choose, use, manage and leave cloud services.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.23 marked as used or not used, a short reason, and its current status.
3. A list of cloud services in use, each with an owner and approval.
4. Notes on who is responsible for what security tasks (you or the provider) for key services.
5. Your exit plan for key services: how you would get your data back.
6. Be able to show the security settings of your most important cloud service.

Information Security Policy

1. Your incident response plan: who does what, how incidents are reported and the steps to handle them.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.24 marked as used or not used, a short reason, and its current status.
3. An up-to-date incident team contact list.
4. Records of a practice exercise or real incident showing the plan was used.
5. Incident team members should be able to explain their role.

1. Incident Response Plan
2. Information Security Roles and Responsibilities Policy

1. Your rules for deciding whether something is a security incident and how serious it is.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.25 marked as used or not used, a short reason, and its current status.
3. Your incident or ticket log showing each event was assessed and given a severity.
4. Notes explaining why some events were not treated as incidents.
5. Be able to show how a reported event is assessed.

Incident Response Plan

1. Your incident handling steps: contain, fix, recover and communicate.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.26 marked as used or not used, a short reason, and its current status.
3. Your incident log showing what was done and when for recent incidents.
4. Records of who was told and when.
5. Be able to walk through how a recent incident was handled.

Incident Response Plan

1. Your process for reviewing incidents afterwards (lessons learned).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.27 marked as used or not used, a short reason, and its current status.
3. Notes from post-incident reviews, including the root cause.
4. Proof that follow-up actions happened, such as updated training or new controls.
5. Be able to explain how lessons are shared with the team.

Incident Response Plan

1. Simple instructions for collecting and preserving evidence during an incident (logs, screenshots, emails).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.28 marked as used or not used, a short reason, and its current status.
3. An incident record showing evidence was saved before clean-up, with who handled it.
4. Log retention settings showing logs are kept long enough to investigate.
5. Be able to explain who may collect evidence and how it is stored.

Incident Response Plan

1. Your business continuity plan, showing how security stays in place during a disruption.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.29 marked as used or not used, a short reason, and its current status.
3. Test results that include security checks.
4. Records from any real disruption showing security was maintained, including emergency access.
5. Be able to explain how security works when normal systems are down.

Business Continuity and Disaster Recovery Plan

1. Your IT recovery plan, with recovery targets: how fast systems must be back (RTO) and how much data you can afford to lose (RPO).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.30 marked as used or not used, a short reason, and its current status.
3. Your business impact analysis showing which systems matter most.
4. Recovery test results showing targets were met.
5. Actions taken to fix problems found in tests.
6. IT should be able to explain recovery roles and steps.

1. Incident Response Plan
2. Business Continuity and Disaster Recovery Plan

1. A list of the laws, regulations and contract requirements that apply to you, each with an owner.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.31 marked as used or not used, a short reason, and its current status.
3. Proof the list is reviewed regularly.
4. Examples linking a requirement to the control that meets it.
5. Be able to explain how you find out about new legal requirements.

1. Legal, regulatory and contractual requirements register

1. Your rules on software licences and using other people's content.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.32 marked as used or not used, a short reason, and its current status.
3. Software licence records matching what is installed.
4. Approval records for installing new software.
5. Be able to show that only approved software is on devices.

1. Legal, regulatory and contractual requirements register
2. Information Security Policy

1. Your records retention policy: how long each type of record is kept and how it is protected.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.33 marked as used or not used, a short reason, and its current status.
3. Examples of records kept for the right time and protected from loss or changes.
4. Records of old information being securely deleted when no longer needed.
5. Be able to show where key records are stored.

1. Document control procedure
2. Access Control Policy
3. Data Management Policy

1. Your privacy policy covering how you protect personal data.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.34 marked as used or not used, a short reason, and its current status.
3. Your list of personal data processing activities, kept up to date.
4. Privacy risk assessments for higher-risk uses of personal data.
5. Records of requests from individuals (for example access or deletion) answered on time.
6. Your privacy lead should be able to explain how privacy rules are met.

Legal, regulatory and contractual requirements register

1. Your plan for an independent review of your security programme, by someone outside the work being checked.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.35 marked as used or not used, a short reason, and its current status.
3. The latest independent review or audit report, shared with management.
4. Actions from the review and their progress.
5. Be able to explain how review results are used.

1. Internal audit procedure
2. Management review procedure
3. Risk Management Policy

1. Your approach to checking that people follow security policies.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.36 marked as used or not used, a short reason, and its current status.
3. Records of compliance checks, such as spot checks or technical scans.
4. Records of problems found and how they were fixed.
5. Managers should be able to explain how they check their area.

1. Internal audit procedure
2. Management review procedure
3. Risk Management Policy

1. Written procedures for key IT and security tasks.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.5.37 marked as used or not used, a short reason, and its current status.
3. Procedures with version numbers, owners and review dates.
4. Proof the procedures are available to the people who need them.
5. Be able to show a task being done the way the procedure says.

Operations Security Policy

1. Your screening policy: what background checks you do for each type of role (for example identity, right to work, references, and criminal checks where the law allows).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.6.1 marked as used or not used, a short reason, and its current status.
3. A list of people who joined in the last 12 months with proof their checks were completed before they started.
4. Records of extra checks for higher-risk roles, such as finance or system administrators.
5. Records showing how delayed or failed checks were approved or handled.
6. HR should be able to explain the screening steps and what happens if a check raises a concern.

Human Resource Security Policy

1. Your employment contract and contractor agreement templates, including security and confidentiality terms.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.6.2 marked as used or not used, a short reason, and its current status.
3. Signed contracts for a few recent starters and contractors.
4. Proof contract terms are updated when policies change.
5. HR should be able to explain how contract terms are kept current.

1. Human Resource Security Policy
2. Information Security Policy
3. Information Security Roles and Responsibilities Policy
4. Code of Conduct

1. Your training plan: what security training each role needs and how often.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.6.3 marked as used or not used, a short reason, and its current status.
3. Training completion records for all staff, including new starters.
4. Copies of the training content, showing it is up to date.
5. Records of extra training for technical roles (developers, administrators, incident team).
6. Results of phishing tests or short quizzes, if you use them.
7. Staff should be able to explain how to report a security problem.

Human Resource Security Policy

1. Your disciplinary process, mentioning security breaches.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.6.4 marked as used or not used, a short reason, and its current status.
3. Records of any security-related disciplinary cases.
4. Proof staff have been told about the process, such as in the handbook.
5. HR should be able to explain how security breaches are handled.

1. Human Resource Security Policy
2. Information Security Policy

1. Your leaver process, including reminding people of duties that continue after they leave (such as confidentiality).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.6.5 marked as used or not used, a short reason, and its current status.
3. Exit letters or checklists showing leavers were reminded of ongoing duties.
4. Records showing responsibilities and access were updated when people changed role.
5. HR should be able to explain how this reminder is given.

1. Human Resource Security Policy
2. Employee Termination Security Policy

1. Your confidentiality agreement (NDA) templates.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.6.6 marked as used or not used, a short reason, and its current status.
3. Signed agreements for staff, contractors and third parties who see confidential information.
4. Proof the templates are reviewed from time to time.
5. Be able to explain when an NDA is required.

Human Resource Resource Security policy

1. Your remote working policy: rules for working from home or other locations.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.6.7 marked as used or not used, a short reason, and its current status.
3. A list of devices showing they meet the rules (encrypted, auto-locking, up to date).
4. Proof staff have accepted the remote working rules.
5. Settings showing remote access uses secure connections and multi-factor login.
6. Remote staff should be able to explain how they keep information safe at home and in public.

1. Access Control Policy
2. Information Security Policy

1. Simple instructions telling staff how to report something suspicious.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.6.8 marked as used or not used, a short reason, and its current status.
3. Examples of reports from staff in your incident or ticket log.
4. Training or poster material showing how to report.
5. Staff should know where and how to report a security concern.

1. Human Resource Security Policy
2. Incident Response Plan
3. Information Security Policy

1. Your physical security policy, defining the secure boundary around offices and equipment rooms.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.1 marked as used or not used, a short reason, and its current status.
3. Site plans or notes showing entry points and how they are secured.
4. Maintenance records for doors, locks and alarms.
5. Be able to show that entrances are secure and in good condition.

1. ISMS scope statement
2. Physical Security Policy
3. Third-Party Management Policy

1. Your rules for entering buildings and handling visitors.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.2 marked as used or not used, a short reason, and its current status.
3. Visitor sign-in records showing visitors were logged and escorted.
4. A list of who has keys or access badges, with approvals.
5. Proof leavers' badges were switched off.
6. Be able to show that entry is controlled and staff challenge strangers.

1. Physical Security Policy
2. Third-Party Management Policy

1. Your rules for securing offices and rooms.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.3 marked as used or not used, a short reason, and its current status.
3. Records of who holds keys or door codes for secure rooms.
4. Proof door codes are changed when people leave.
5. Be able to show that secure rooms are locked and sensitive information can't be seen from outside.

1. Physical Security Policy
2. Third-Party Management Policy

1. Your rules for monitoring premises (alarms, cameras, security staff).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.4 marked as used or not used, a short reason, and its current status.
3. Alarm and camera test or maintenance records.
4. Records of how long footage is kept and who can view it.
5. Be able to show monitoring equipment working and covering key areas.

1. Physical Security Policy
2. Third-Party Management Policy

1. Your assessment of physical risks such as fire, flood and power cuts.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.5 marked as used or not used, a short reason, and its current status.
3. Maintenance records for fire detection, extinguishers and other protections.
4. Records of any incidents, such as leaks, and the response.
5. Be able to show how key equipment is protected from these risks.

1. Physical Security Policy
2. Third-Party Management Policy

1. Your rules for working in secure areas such as server or records rooms (for example no unaccompanied visitors, no photos).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.6 marked as used or not used, a short reason, and its current status.
3. A list of people allowed into secure areas, with approvals.
4. Entry records for secure areas showing only authorized people went in.
5. Escort records for visitors or contractors in secure areas.
6. Signs or notices displaying the rules at the entrance.
7. Be able to show that the rules are followed in practice.

1. Physical Security Policy
2. Third-Party Management Policy

1. Your clear desk and clear screen policy.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.7 marked as used or not used, a short reason, and its current status.
3. Results of clear desk spot checks.
4. Settings showing screens lock automatically after a short time.
5. Records of follow-up when spot checks found problems.
6. Be able to show desks and printers free of sensitive papers.

1. Information Security Policy
2. Physical Security Policy

1. Your rules for where equipment is placed and how it is protected.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.8 marked as used or not used, a short reason, and its current status.
3. A list or plan of where key equipment is located.
4. Notes on protections in place, such as locked racks, privacy screens or raised floors.
5. Maintenance records for protective equipment.
6. Records of any damage or incidents involving equipment.
7. Be able to show that equipment is away from public view and protected from damage.

1. Physical Security Policy
2. Third-Party Management Policy

1. Your rules for equipment used outside the office (for example laptops and phones).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.9 marked as used or not used, a short reason, and its current status.
3. A list of devices used off-site showing they are encrypted and can be located or wiped.
4. Records of lost or stolen devices and what was done.
5. Proof staff have accepted the rules for travelling with equipment.
6. Staff should be able to explain how they protect devices when travelling.

1. Asset Management Policy
2. Information Security Policy

1. Your rules for USB drives, external disks and other storage media.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.10 marked as used or not used, a short reason, and its current status.
3. Approval records for using removable media.
4. Settings showing removable media is blocked or encrypted.
5. Records of secure destruction of old media.
6. Be able to show where any sensitive media is stored.

1. Asset Management Policy
2. Data Management Policy

1. Your requirements for power, cooling and internet connections for key equipment.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.11 marked as used or not used, a short reason, and its current status.
3. Test and maintenance records for backup power and cooling.
4. Records of past outages and the response.
5. If you use a data centre or cloud provider, their reports covering these protections.
6. Be able to show protections in your equipment room, if you have one.

1. Physical Security Policy
2. Third-Party Management Policy

1. Your requirements for protecting power and network cables.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.12 marked as used or not used, a short reason, and its current status.
3. Cable diagrams or labelling records.
4. Records showing unused network points are switched off.
5. Maintenance records for cabling work.
6. Be able to show that cables are tidy, protected and not exposed in public areas.

1. Physical Security Policy
2. Third-Party Management Policy

1. Your equipment maintenance process.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.13 marked as used or not used, a short reason, and its current status.
3. Maintenance records showing equipment is serviced as recommended.
4. A list of approved maintenance providers.
5. Records showing data was removed or protected before equipment went out for repair.
6. Be able to explain how data is protected when equipment is repaired off-site.

1. Physical Security Policy
2. Third-Party Management Policy

1. Your process for securely wiping or destroying equipment before reuse or disposal.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.7.14 marked as used or not used, a short reason, and its current status.
3. Wiping records or certificates of destruction.
4. Asset inventory entries showing disposed items were marked as disposed.
5. Your agreement with any disposal company.
6. Be able to explain how drives are wiped before reuse.

1. Asset Management Policy
2. Data Management Policy

1. Your device policy: security rules for laptops, phones and tablets.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.1 marked as used or not used, a short reason, and its current status.
3. A list of company devices showing they are managed and meet the rules (encryption, updates, screen lock, malware protection).
4. Examples of devices that fell out of line and how they were fixed.
5. Proof staff accepted the device rules.
6. Be able to show how settings are enforced on devices.

1. Asset Management Policy
2. Data Management Policy
3. Information Security Policy
4. Operations Security Policy

1. Your rules for administrator (privileged) access: who gets it and how it is controlled.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.2 marked as used or not used, a short reason, and its current status.
3. A list of all administrator accounts, each with a reason and approval.
4. Records of regular reviews of administrator access.
5. Settings showing admins use separate accounts and multi-factor login.
6. Administrators should be able to explain when they use their admin account.

Access Control Policy

1. Your access control policy explaining how access to information is restricted.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.3 marked as used or not used, a short reason, and its current status.
3. Permission settings for sensitive folders and systems matching approved access.
4. Sharing settings showing public or external sharing is controlled.
5. Records of approvals for external sharing.
6. Be able to show access restrictions on a sensitive folder or system.

Access Control Policy

1. Your rules on who can see and change source code.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.4 marked as used or not used, a short reason, and its current status.
3. A list of who can access your code repositories, reviewed regularly.
4. Settings showing changes need review and approval before being merged.
5. Proof that leavers lost repository access.
6. Be able to show the repository protection settings.

Access Control Policy

1. Your login rules: multi-factor authentication, account lockout and session timeouts.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.5 marked as used or not used, a short reason, and its current status.
3. Settings from key systems showing these rules are switched on.
4. A list of any exceptions, with approvals.
5. Records of locked accounts or failed logins being looked into.
6. Be able to show a login to a key system.

Access Control Policy

1. Your process for monitoring system capacity (storage, processing power, bandwidth).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.6 marked as used or not used, a short reason, and its current status.
3. Capacity monitoring reports or alerts.
4. Capacity plans for key systems.
5. Records of capacity issues and how they were fixed.
6. IT should be able to explain how they spot capacity problems early.

Operations Security Policy

1. Your malware protection policy.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.7 marked as used or not used, a short reason, and its current status.
3. A report showing malware protection is installed, switched on and up to date on all devices and servers.
4. Records of malware detections and how they were handled.
5. Awareness material warning staff about malware.
6. Be able to show the protection settings.

1. Operations Security Policy
2. Information Security Policy

1. Your vulnerability management process: how often you scan, and how quickly you fix issues by severity.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.8 marked as used or not used, a short reason, and its current status.
3. Recent vulnerability scan reports.
4. Examples of high and critical issues showing they were fixed on time.
5. Patch status reports for devices and servers.
6. Penetration test reports and the fix tracking.
7. IT should be able to explain how they decide what to fix first.

1. Operations Security Policy
2. Risk Management Policy

1. Your standard secure settings (baselines) for key systems.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.9 marked as used or not used, a short reason, and its current status.
3. Records showing systems are built using the baselines.
4. Reports showing settings haven't drifted.
5. Change records for any setting changes.
6. Be able to compare one system against its baseline.

Operations Security Policy

1. Your rules for deleting information when it is no longer needed.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.10 marked as used or not used, a short reason, and its current status.
3. Records showing data was deleted on schedule.
4. Records of customer deletion requests being completed.
5. Certificates or confirmation of deletion from suppliers where relevant.
6. Be able to explain how deletion is carried out and checked.

Data Management Policy

1. Your rules for hiding or scrambling sensitive data (data masking) where full data isn't needed.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.11 marked as used or not used, a short reason, and its current status.
3. Examples of masked data in test systems or reports.
4. Approvals for any exceptions where real data was used.
5. A list of which data fields must be masked.
6. Be able to show masked data in a test environment.

Data Management Policy

1. Your rules to stop sensitive data leaking out (data leakage prevention).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.12 marked as used or not used, a short reason, and its current status.
3. Settings showing controls on email, file sharing, uploads and USB drives.
4. Alerts raised and how they were checked.
5. Approved exceptions with reasons.
6. Be able to show a control blocking or warning about sensitive data being sent out.

Data Management Policy

1. Your backup policy: what is backed up, how often, how long it is kept and how backups are protected.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.13 marked as used or not used, a short reason, and its current status.
3. Backup logs showing backups run successfully.
4. Restore test records showing backups actually work.
5. Settings showing backups are protected and stored separately from live systems.
6. Records of failed backups and how they were fixed.
7. Be able to explain what happens when a backup fails.

Operations Security Policy

1. Your requirements for keeping key systems available, including backup systems (redundancy).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.14 marked as used or not used, a short reason, and its current status.
3. A diagram or description showing backup systems for critical services.
4. Failover test results.
5. Uptime or availability reports.
6. IT should be able to explain how they know redundancy is working.

1. Business Continuity and Disaster Recovery Plan
2. Operations Security Policy

1. Your logging policy: which activities are recorded, how long logs are kept and how they are protected.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.15 marked as used or not used, a short reason, and its current status.
3. Settings showing logging is switched on for key systems, including administrator activity.
4. Log retention settings.
5. Proof that logs can't be changed or deleted by ordinary users.
6. Be able to show a sample log with who did what and when.

Operations Security Policy

1. Your monitoring process: what is watched and what happens when something unusual happens.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.16 marked as used or not used, a short reason, and its current status.
3. Alert records and the tickets showing they were investigated.
4. A screenshot or export of alert settings showing thresholds and who gets notified.
5. Reports of monitoring trends reviewed by IT.
6. Be able to show who receives alerts and how quickly they respond.

Operations Security Policy

1. Your rule that all systems use the same trusted time source.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.17 marked as used or not used, a short reason, and its current status.
3. Settings from key systems showing they sync to the approved time source.
4. A sample of logs from different systems showing matching timestamps.
5. Records of any time sync problems and how they were fixed.
6. Your list of key systems covered by the rule.
7. Be able to show timestamps lining up across two systems.

Operations Security Policy

1. Your rules for powerful utility programs that can override security settings.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.18 marked as used or not used, a short reason, and its current status.
3. A list of who can use these programs, with approvals.
4. Settings restricting their use to authorized people.
5. Logs showing when they were used.
6. Records of regular reviews of who has access.
7. Be able to explain why each person needs access.

1. Access Control Policy
2. Operations Security Policy

1. Your process for approving software installation.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.19 marked as used or not used, a short reason, and its current status.
3. A list of approved software.
4. Approval records for recent installs.
5. Settings stopping ordinary users from installing software.
6. Reports of unapproved software found and removed.
7. Be able to show that a normal user can't install unapproved software.

1. Information Security Policy
2. Operations Security Policy

1. Your network security requirements.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.20 marked as used or not used, a short reason, and its current status.
3. An up-to-date network diagram.
4. Records of firewall rule reviews.
5. Configuration records for network devices.
6. Records of network security changes and their approval.
7. Be able to explain how your network is protected from outside threats.

Operations Security Policy

1. Your security requirements for network services (internet, VPN, hosting connections).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.21 marked as used or not used, a short reason, and its current status.
3. Contracts or service descriptions from network providers showing security features.
4. Monitoring records for network services.
5. Records of service issues and how they were handled.
6. A list of network services in use with owners.
7. Be able to explain how network services are secured.

1. Operations Security Policy
2. Third-Party Management Policy

1. Your rules for separating networks (for example guests, staff, servers, test and live).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.22 marked as used or not used, a short reason, and its current status.
3. A network diagram showing separate segments.
4. Rules controlling traffic between segments.
5. Records of reviews of those rules.
6. Approvals for any exceptions.
7. Be able to show that the guest network can't reach internal systems.

Operations Security Policy

1. Your web filtering rules: which types of websites are blocked.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.23 marked as used or not used, a short reason, and its current status.
3. Filtering settings and blocked categories.
4. Records of blocked attempts.
5. Approval records for any exceptions.
6. Reviews of the blocked list.
7. Be able to show a blocked website warning.

Operations Security Policy

1. Your encryption policy: when encryption must be used and how keys are managed.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.24 marked as used or not used, a short reason, and its current status.
3. Settings showing sensitive data is encrypted when stored and when sent.
4. A list of encryption keys and certificates with owners and expiry dates.
5. Records of keys being changed or revoked.
6. Proof certificates are renewed before they expire.
7. Be able to show encryption settings on a key system.

Cryptography Policy

1. Your secure development policy: how security is built into each stage of building software.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.25 marked as used or not used, a short reason, and its current status.
3. Records showing security steps at each stage, such as design reviews and testing.
4. Training records for developers.
5. Release checklists that include security.
6. Developers should be able to explain how security fits into their work.

Secure Development Policy

1. Your process for defining security requirements for new or changed applications.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.26 marked as used or not used, a short reason, and its current status.
3. Security requirements written into feature or project specifications.
4. Test results showing those requirements were checked.
5. Sign-off before release.
6. Product owners should be able to explain how requirements are decided.

1. Secure Development Policy
2. Third-Party Management Policy

1. Your secure design principles (for example least privilege and defence in depth).
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.27 marked as used or not used, a short reason, and its current status.
3. Design documents showing the principles were applied.
4. Records of security design reviews.
5. Proof the principles are reviewed and updated.
6. Architects or senior developers should be able to explain the principles.

Secure Development Policy

1. Your secure coding standards.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.28 marked as used or not used, a short reason, and its current status.
3. Code review records showing security was checked.
4. Automated code scan results and fixes.
5. Developer training on secure coding.
6. Be able to walk through a recent code review.

Secure Development Policy

1. Your security testing requirements for new releases.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.29 marked as used or not used, a short reason, and its current status.
3. Security test results for recent releases.
4. Acceptance test records.
5. Approvals for any release that went out with known issues.
6. Testers should be able to explain what security testing covers.

Secure Development Policy

1. Your requirements for outsourced (third-party) software development.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.30 marked as used or not used, a short reason, and its current status.
3. Contracts with external developers including security terms.
4. Records of how their work was supervised.
5. Test results for code they delivered.
6. Be able to explain how outsourced work is checked.

1. Secure Development Policy
2. Third-Party Management Policy

1. Your rules for keeping development, test and live (production) systems separate.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.31 marked as used or not used, a short reason, and its current status.
3. Access lists showing who can reach the live environment.
4. A diagram or description showing separate environments.
5. Approvals for any developer access to live systems.
6. Be able to show the separation in practice.

1. Operations Security Policy
2. Secure Development Policy

1. Your change management process: how changes are requested, assessed, approved, tested and rolled back if needed.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.32 marked as used or not used, a short reason, and its current status.
3. Recent change tickets showing approval, testing and a back-out plan.
4. Emergency change records reviewed after the fact.
5. Your change log or calendar.
6. Be able to walk through how a change gets approved.

1. Operations Security Policy
2. Secure Development Policy

1. Your rules for choosing and protecting test data.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.33 marked as used or not used, a short reason, and its current status.
3. Approvals for any use of real data in testing.
4. Records showing test data was removed when no longer needed.
5. Settings restricting access to test data.
6. Be able to explain where test data comes from.

1. Data Management Policy
2. Secure Development Policy

1. Your process for planning audits and technical tests on live systems so they don't cause disruption.
2. Your Statement of Applicability (SoA: the list of all 93 controls showing which you use and why) with A.8.34 marked as used or not used, a short reason, and its current status.
3. Plans and approvals for recent audits or technical tests.
4. Records of when tests ran and who ran them.
5. Notes of any disruption and the follow-up.
6. IT should be able to explain how testing impact is kept low.

1. Internal audit procedure
2. Operations Security Policy
3. Risk Management Policy