93 controls · ISO/IEC 27001:2022, Annex A
The international standard for running information security as a managed system, and the certificate overseas and enterprise customers most often ask a small supplier for. It is issued by an accredited certification body after that body audits you, so Virtosic can get you ready for the audit and can never grant the certificate itself. Annex A is a reference set you select from rather than a list you must complete: a control can be left out where your Statement of Applicability records why, which makes an honest exclusion here a real answer rather than a way of avoiding the work.
You have security rules written down, signed off by whoever runs the business, and your team has actually seen them.
A set of security policies exists in writing, is owned and approved at the top of the organisation, reaches the people expected to follow it, and is revisited on a schedule rather than left to age.
Every part of security has a name against it, so nothing sits in the gap between two people who each assumed the other had it.
Each part of the security effort is allocated to a role, so that asset ownership, risk work, incident leadership and policy upkeep each have somebody accountable rather than falling between people.
No one person can start and finish a sensitive job alone, so a mistake or a misuse is seen by somebody else along the way.
Duties that conflict with one another are held by different people, so that no individual can both carry out a damaging action and conceal it.
Whoever leads the business expects the security rules to be followed and makes that clear, rather than leaving it to good intentions.
Management actively expects everyone to work to the security rules and says so, rather than publishing the rules and hoping. Without this the whole policy set is advisory in practice.
You know who to call at the regulator or the police if something serious happens, and you worked that out before you needed it.
The organisation works out in advance which outside authorities it might need - a regulator, law enforcement, a national cyber body - and keeps a route to them that works under pressure.
You have a way of hearing what others in your line of work are seeing, rather than only finding out when it happens to you.
Links are kept with security forums, industry bodies or professional groups, so the organisation hears about threats and practice from outside its own four walls.
You gather information about the attacks hitting businesses like yours, and you change something because of it rather than just reading it.
Information about who is attacking organisations like this one, and how, is collected, judged for relevance and turned into a decision. Intelligence nobody acts on does not satisfy this.
Security gets considered at the start of a project, not in the week before launch when changing anything is expensive.
Security questions are asked inside projects of every kind from the start, at the point when the answers are still cheap to act on.
You have a list of the information you hold and the kit and services it sits on, and each entry has an owner's name against it.
A maintained record of the information the organisation holds and the things that carry it - hardware, software, services, facilities - with an owner recorded against each entry.
Your team knows what they may and may not do with company information, devices and accounts, because you put it in writing.
Rules say what people may and may not do with the organisation's information, devices and accounts, and everyone who handles them has been told what those rules are.
When someone leaves or moves on, the laptop, phone, keys and documents come back, and you can say what is still out there.
Everything issued to a person comes back when their employment, contract or arrangement ends or changes - devices, media, credentials, documents, keys.
You sort your information by how sensitive it is, so the things that would really hurt you get more protection than the rest.
Information is graded by what it would cost the organisation if it leaked, was altered, or became unavailable, so that protection can be matched to value instead of applied evenly.
Sensitive files, emails and printouts carry a marking, so nobody has to guess how carefully to treat what is in front of them.
The grading travels with the information as a visible marking, so that anyone who receives a file, an email or a printout can see how careful to be with it.
You have rules for sending information out, whether by email, chat, post or a USB stick, and for what may be discussed where.
Rules and, where another organisation is involved, agreements govern how information moves - electronically, on physical media, on paper, and in conversation.
You have decided who may reach what, based on what their job needs, and your systems apply that decision rather than trusting habit.
Rules decide who may reach which information and services, physically and in software, based on what the work genuinely needs and how sensitive the thing being reached is.
Every person, service and device using your systems has its own identity, set up on purpose and removed when it is finished with.
Identities - for people, and for the services and devices that act on their own - are created deliberately, kept accurate while they are in use, and removed once they are no longer needed.
Passwords and keys are handed out, stored and changed carefully, and your team knows not to share or reuse them.
The secrets that prove identity - passwords, keys, tokens - are issued, stored, handed over and replaced under control, and the people holding them have been told how to look after them.
Access is granted on approval, looked over from time to time, and taken away promptly when a job changes or somebody leaves.
Access is granted, reviewed, adjusted and withdrawn across the whole time a person holds it, following the organisation's own access rules rather than case by case.
You have a way of judging the security risk each supplier brings, because giving them the work does not give them the responsibility.
There is a defined way of identifying and managing the security risk that comes with using a supplier's products or services, because handing out the work does not hand out the risk.
What you expect a supplier to do about security is written into the contract, so you could point at it if they fell short.
What the organisation expects of a supplier on security is written into the agreement with them, which is what makes it enforceable rather than assumed.
You have thought about who supplies your suppliers, because a weakness several steps back still arrives on your systems.
The security risk carried by the chain behind a technology product or service is managed, including the suppliers and components your own suppliers depend on.
You check suppliers are doing what they promised, and when one changes how their service works you look at what that changes for you.
Supplier delivery is checked against what was agreed, and a change the supplier makes to how their service works is treated as a change to yours rather than quietly absorbed.
You know which parts of security your cloud providers handle and which stay with you, and you know how you would get your data back out.
Cloud services are chosen, used and eventually left under rules the organisation has set, with a clear understanding of which security duties the provider takes and which stay behind.
You decided in advance who does what during a security incident, so the first ten minutes are not spent working out who to call.
Before anything happens, the organisation settles how incidents will be handled - the process, who plays which part, and how decisions get made - and tells the people involved.
Somebody looks at each reported problem and decides whether it counts as a real incident, rather than leaving it an open question.
Each reported event is assessed and a recorded decision is made about whether it counts as a security incident, so nothing stays permanently ambiguous.
When something is confirmed as an incident you follow the plan you wrote, and you write down what you actually did.
Confirmed incidents are handled by following the procedures the organisation wrote, and what was actually done is recorded as it happens.
After an incident you change something, so the same gap does not let the same thing happen again next quarter.
What an incident revealed is fed back into the controls, so that the same weakness does not produce the same incident again.
You know how to preserve logs and devices after an incident, because the normal rush to clean up destroys what an investigation needs.
There is a way of identifying, gathering and preserving evidence about an incident in a form that would still be worth something to an investigator, an insurer or a court later on.
Your security does not fall away during a crisis. You planned how to keep it up while running on backup arrangements.
Security is held at a planned level while the organisation is disrupted, instead of being the first thing dropped in the effort to keep trading.
You worked out how fast each system has to come back, and you have tested that your technology can really meet that.
Technology recovery is planned, built and tested against recovery times the business has actually agreed, rather than against whatever the technology happens to manage.
You know which laws and contract terms apply to the information you hold, and you can say how you meet each one.
The legal, regulatory and contractual obligations bearing on information security are identified, kept current, and matched to how each one is met.
You use software you are actually licensed for, and you protect your own material from being taken.
Intellectual property is protected in both directions: the organisation's own material, and other people's - software licensing being where this most often bites.
Records you have to keep are protected from being lost, altered or seen by the wrong people for the whole time you keep them.
Records are protected from loss, destruction, falsification and unauthorised access or release, for the whole period the organisation is required to keep them.
You know what personal information you hold about people, and what the law where you operate requires you to do with it.
The organisation identifies what it owes to the people whose personal information it holds under the law and contracts that apply to it, and meets those obligations.
Somebody who does not run your security looks it over now and then, because it is hard to spot the gaps in your own arrangements.
The organisation's security arrangements are reviewed by someone independent of the work being reviewed, on a planned schedule and after significant change.
You check that your written rules are the ones people really follow, rather than assuming the policy and the practice still match.
The organisation regularly checks that its own written rules are the rules being followed in practice, rather than assuming policy and behaviour still match.
The routine tasks that keep your systems running are written down, so they do not live only in one person's head.
The procedures for running the systems that process information are written down and available to the people who have to run them.
You check people out before they start, to a depth that matches what they will be trusted with.
Background checks are carried out on candidates before they join, to a depth that matches what they will be trusted with and within the limits of local law.
Security responsibilities are written into the contract people sign, so they are part of the job rather than an afterthought.
The employment agreement states the security responsibilities carried by the person and by the organisation, so they are part of the job rather than an add-on.
Your team, contractors included, gets security training when they join and regular reminders after that.
Everyone who works for the organisation, contractors included, gets security awareness and training suited to their role, refreshed as the rules and the threats change.
There is a known process for what happens when somebody breaks a security rule, and your team knows about it in advance.
There is a formal process for acting on a security breach by a member of staff, and people know it exists before anyone needs it.
The duties that outlast the job, like keeping your information confidential, are spelled out and put to the person on the way out.
The duties that outlive the job - confidentiality above all - are defined, put to the person as they leave or move, and remain enforceable afterwards.
The people and companies who see your confidential information have signed something saying they will keep it that way.
Confidentiality agreements reflecting what the organisation actually needs protected are identified, kept current, and signed by staff and by outside parties.
The rules still apply at somebody's kitchen table, and you have said what safe working from home or on the move looks like.
Measures protect information reached, handled or stored away from the organisation's premises, where the risks are different rather than smaller.
Anyone can report something that looks wrong, quickly, and they know exactly where to send it without fearing the reaction.
There is a route anyone can use to report something that looks wrong, quickly, and people have been pointed at it and are expected to use it.
You have drawn a line around the places your information lives - walls, doors, a locked room - rather than leaving them open.
Boundaries are defined around the areas holding information and the equipment that processes it, so that there is a line to control rather than an open floor.
Only approved people get into the areas holding your information, and something decides that rather than an unlocked door.
The way into a protected area is controlled: something decides who gets through, and there is a record of who did.
Your offices and server rooms are set up with security in mind, not furnished first and thought about later.
Offices, rooms and facilities are designed and set up with their security in mind, rather than fitted out first and worried about afterwards.
You would know if somebody got into your premises who should not be there, rather than finding out when something is missing.
Premises are watched on an ongoing basis for people getting in who should not be there, so that an intrusion is noticed rather than reconstructed afterwards.
You have thought about fire, water, power and weather, not only about people. A flooded cupboard loses data just as well.
Protection is in place against fire, water, extreme weather, power events and deliberate physical damage to the places where information is held.
You have rules for what happens inside your most sensitive areas: who may be there alone, and what may be brought in or recorded.
Rules govern how people behave inside a protected area - who may be there unaccompanied, and what may be brought in, used or recorded.
Papers get put away and screens lock when people step away, so a walk past a desk does not show anyone your customers' data.
Papers and removable media are put away and screens are cleared or locked when a workspace is left unattended.
Your equipment sits where spills, heat and passers-by cannot get at it, and where nobody can read a screen or unplug it in passing.
Equipment is placed and protected so that environmental hazards, casual observation and accidental interference do not reach it.
Laptops, phones and files taken out of the building are protected for the risks out there, which are not the risks in the office.
Assets taken outside the organisation's premises are protected for the risks that exist out there, which are different from the ones inside.
Drives, discs, tapes and USB sticks are looked after from the day you get them to the day you destroy them.
Storage media are managed across their whole life - acquired, used, carried, stored and destroyed - according to how sensitive what they carry is.
Your systems are protected against the power, cooling and connectivity they rely on failing, because losing those loses the systems.
Equipment that processes information is protected against failure of the utilities it depends on, such as power, cooling and communications links.
Your power and network cables are protected from being cut, tripped over or quietly tapped into.
Power and data cabling is protected from being intercepted, interfered with or damaged, including where it runs through areas the organisation does not control.
Equipment is serviced properly, and you make sure a repair does not become a way for your information to leave the building.
Equipment is maintained properly so that the information depending on it stays available, accurate and confidential - including while the maintenance itself happens.
Before a machine is sold, recycled or passed to a colleague, someone checks the data really is gone. Deleting a file is not wiping a disk.
Before equipment holding storage media is disposed of or handed on, someone verifies that sensitive information and licensed software have genuinely been removed.
Laptops, phones and tablets that reach your information are protected, including the personal ones if you let those in.
Information held on, or reachable from, the devices people work on is protected - including devices the organisation does not own but allows in.
Administrator rights go only to those who genuinely need them, and you can say who holds them today.
Elevated access is handed out sparingly, for a reason, to people who are known, and taken back when the reason ends.
Having an account is not the same as seeing everything. Each person reaches only the information their job needs.
Access to information and to what an application can do with it is restricted inside the system, following the organisation's access rules.
Only the right people can read or change your source code and the tools that build it.
Read and write access to source code, development tools and software libraries is controlled, because the code is where a change reaches every customer at once.
How people prove who they are matches what they are getting at, so the sensitive systems ask for more than a password.
How strongly a person or system has to prove identity is chosen to match the sensitivity of what is behind the login and the access rules that apply to it.
You watch whether your systems, storage and people have enough headroom, so nothing runs out at the worst possible moment.
Use of the resources the organisation depends on is watched and adjusted against what is needed now and what will be needed, so nothing runs out unnoticed.
You have malware protection running where it matters, and your team knows what a suspicious attachment looks like.
Technical protection against malicious software is in place and is backed by people who know what a suspicious message or attachment looks like.
You find out about weaknesses in the software you run, work out whether they reach you, and fix the ones that do.
The organisation finds out about weaknesses in the software it runs, works out how exposed it actually is to each one, and acts on that judgement.
You have written down how your systems should be set up, and something checks they have not drifted away from it.
How hardware, software, services and networks should be set up is decided and written down, applied, and checked afterwards for drift.
You delete information once you no longer need it, everywhere it lives, rather than keeping everything forever by default.
Information is deleted once it is no longer needed, wherever it ended up - live systems, devices, backups, log stores and services run by somebody else.
Where somebody only needs part of a record, they see only that part, so full card or health details are not on show by default.
Where somebody's work needs only part of a sensitive record, the rest is hidden or replaced, so full details are not on display by default.
You have something in place to stop sensitive information walking out by email, upload or copy, and to tell you when it nearly did.
Measures on the systems, networks and devices handling sensitive information detect and stop it leaving by routes it should not.
Your data is backed up on a schedule you decided, and you have restored from a backup to check that it really works.
Copies of information, software and systems are taken to a decided plan and restored from often enough to know that the copies actually work.
The systems you cannot afford to lose have something to fall back on, sized to how long you could really be without them.
The systems the organisation cannot afford to lose have enough spare capacity or standby capability to meet the availability the business decided it needs.
Your systems keep logs of what happened, the logs cannot be quietly edited, and somebody actually reads them.
Logs of activity, exceptions and faults are produced, kept, protected from alteration, and looked at - a log nobody reads only helps after the fact.
Something watches your systems and network for behaviour that is out of the ordinary, and a person acts on what it flags.
Networks, systems and applications are watched for behaviour that is out of the ordinary, and what turns up is followed through to a judgement.
Your machines all take the time from the same trusted source, so timestamps in different logs can be compared and believed.
Systems agree on what time it is, taken from a source the organisation trusts, so that records from different machines can be lined up and believed during an investigation.
The powerful tools that can bypass your normal protections are locked down, rather than sitting there for anyone to run.
Tools capable of overriding the organisation's own system and application controls are restricted to the few people who need them and watched when used.
Software gets onto your live systems through a controlled route, not because somebody decided to install it that afternoon.
Software reaches live systems through a controlled route, so that what is running there is what somebody decided should be running there.
Your network is set up and managed on purpose, so what crosses it is protected rather than left to reach whatever it can.
Networks and the devices on them are set up, managed and controlled deliberately, so that what travels across them is protected on the inside as well as at the edge.
For each network service you use, you know what security it comes with and what you were promised, and you check you get it.
For every network service used, whether run in-house or bought in, the security it provides and the service levels promised are identified and then checked against reality.
Your network is divided up, so a guest connection or one compromised laptop cannot simply reach everything else you own.
Groups of systems, services and users are separated from one another on the network, so that reaching one does not mean reaching everything.
You limit which websites work machines can reach, so a single wrong click has fewer places to go.
Which external websites work systems may reach is managed, reducing how much malicious content a single wrong click can pull in.
You have decided where encryption is used and how, and you know where the keys live and how you would replace one in a hurry.
The organisation has a settled position on where encryption is used and how, including how keys are generated, stored, replaced and retired across their life.
If you build software, security is part of how you build it from the start rather than a review in the final week.
Rules for building software and systems securely are set and applied across the whole of development, rather than as a check at the end.
When you build or buy an application, the security it needs is decided and agreed up front, not discovered afterwards.
The security an application needs is worked out and agreed when it is being built or bought, at the point when it can still shape the result.
You have written down the security principles your systems are built to, so each new piece is not designed from scratch by whoever is free.
The organisation writes down the principles its systems are engineered to, keeps them current, and applies them to the work, so each new piece is not designed from scratch.
The people writing your code know the common ways code gets broken into, and they write to avoid them.
Code is written to principles that avoid the well-known ways software gets broken into, and those principles are actually applied rather than merely known.
Security testing happens before something is accepted and goes live, not once real customer data is already flowing through it.
Security testing is defined and carried out during development and before something is accepted into live use.
If somebody else writes your software, you set the security expectations and check the work rather than only taking delivery.
Where software is built by somebody else, the organisation sets the security expectations, watches the work and reviews what comes back.
Your live systems are kept apart from where you build and test, so an experiment cannot reach real customers.
Development, test and live environments are kept apart and protected from one another, so that work in progress cannot reach real customers.
Changes to your systems are proposed, reviewed and recorded, so you can say what changed, when, and who agreed to it.
Changes to systems and to the facilities that process information go through a change management procedure, rather than depending on the care of whoever makes them.
You do not copy live customer data into a test system without thinking, because test systems are watched far less carefully.
Information used for testing is chosen, protected and managed deliberately, because test environments are watched far less closely than live ones.
When an auditor or tester pokes at your live systems, it is agreed in advance so the check does not take the business down.
Testing that touches live systems as part of an audit or assurance activity is planned and agreed with management first, so the check does not become the outage.
Our own summary of what each control area covers, written to be read by someone without a compliance background. It is not the text of the standard, and it is not a substitute for it - where a framework is a copyrighted document, you will need your own copy. Nothing here is legal advice or an assurance that following it satisfies an auditor.