38 controls · 2017 TSC (rev. 2022)
The report enterprise customers most often ask for before they will sign. It shows an independent auditor checked how you protect their data.
You have written down how people at your company are expected to behave, and everyone has seen it.
Conduct expected of everyone in the business is written down, visible, and applied to whoever breaks it - including people senior enough to expect otherwise.
Someone above the day-to-day team - a board, an owner, or an advisor - reviews how security is being run.
Someone above management - a board, an advisory group, an owner not running things day to day - reviews how security is handled, and is independent enough to say it is inadequate.
It is clear who is responsible for what, including who owns security decisions.
Reporting lines and decision rights are defined, so it is clear who may approve something, who must be told, and who answers for the outcome.
The people handling security work are qualified to do it, and they get training to stay current.
The people holding security responsibilities are chosen and trained for them, and a gap in skill is treated as something to close rather than work around.
When someone does not follow a security rule, there is a consequence and it is applied consistently.
Security duties carry consequences. Performance, incentives and correction reach the people who hold them, so responsibility is real rather than nominal.
You collect enough real information about your systems to know whether your controls are actually working.
Decisions about security are made from information current and complete enough to support them, rather than from whatever happened to be to hand.
Your team knows what the security rules are and who to tell when something looks wrong.
People inside the business are told what security expects of them, and have a route to raise a problem that reaches somebody able to act on it.
Customers, vendors, and partners know how to report a security problem to you, and you tell them when one affects them.
Customers, suppliers and regulators are told what they need to know about security matters affecting them, through a channel that is defined rather than improvised.
You have said clearly what you are protecting and why, so you can judge what counts as a risk.
Objectives are stated clearly enough that a risk to them can be recognised. A risk cannot be weighed against a goal nobody has written down.
You keep a list of the things that could go wrong, and you have thought about how likely and how serious each one is.
Threats to those objectives are found, sized and judged deliberately, so what gets attention is chosen rather than whatever surfaced most recently.
Your risk list includes the possibility that someone inside the company misuses their access.
Risk assessment includes the possibility that someone inside the business acts dishonestly, which ordinary threat modelling tends to skip.
When something big changes - a new system, a new office, a new type of customer data - you reassess the risks.
Changes to the business, its systems or its suppliers are examined for what they alter about the risk picture, rather than assessed once and left.
You check periodically that your security controls are still working, rather than assuming they are.
Controls are checked while they are running, not only when they were designed, so one that quietly stopped working is discovered.
When a check finds a problem, it reaches the person who can fix it, quickly.
Weaknesses that turn up are judged for seriousness, reported to people able to act, and tracked until they are actually closed.
For each risk you identified, you have chosen a specific measure that reduces it.
Controls are chosen to address the risks that were actually identified, rather than adopted as a standard set that may or may not fit this business.
Your technology itself enforces the rules where possible, instead of relying on people to remember them.
The technology everything else runs on carries its own controls over access, change and operation, because application controls rest on the infrastructure beneath them.
Your policies are written down and there are step-by-step procedures for following them.
What has been decided is written as policy and turned into procedures people follow, so a control exists in practice rather than only in intent.
Access to your systems and data requires a login, and that login is properly protected.
Reaching systems and data requires authenticating first, and the means of doing so is itself protected and configured deliberately.
Someone approves each new account before it is created - accounts do not just appear.
Access is granted through an approval that is recorded, so every account can be traced back to a decision somebody made.
When someone changes role or leaves, their access changes or is removed the same day.
Access changes when a person's role changes and ends when they leave, rather than accumulating quietly over years.
Only the right people can physically walk up to your servers, network equipment, or offices holding sensitive data.
Places holding systems or data - offices, racks, storage - admit only the people entitled to be there.
Old laptops, drives, and phones are wiped properly before they are sold, recycled, or thrown away.
Hardware and media leaving the business are cleared first, because a decommissioned laptop is a complete copy of whatever was on it.
Your systems are defended against attacks coming from the internet.
The boundary between the business and everything outside it is defended, so reaching in requires getting past something.
Sensitive data is encrypted when it travels, and people cannot copy it somewhere it should not go.
Data moving between people, systems and organisations is controlled and protected on the way, so it goes where it was meant to and arrives unread.
You would notice if malware or unapproved software were installed on a company device.
Software nobody approved is prevented where it can be and noticed where it cannot, so what runs on the estate is what was intended to.
You would find out if a system were misconfigured or if a new weakness were discovered in software you use.
Systems are watched for drift from their intended configuration and for known weaknesses, so both are found before somebody else finds them.
Something is watching your systems for unusual activity, and a person looks at what it flags.
Systems are monitored for behaviour that does not fit, and what turns up is read by someone who can tell an incident from noise.
When an alert fires, someone decides whether it actually matters and acts on it.
Events are assessed to decide whether something has actually gone wrong, so a real incident is not filed alongside routine alerts.
You have a written plan for what to do during a security incident, and you follow it.
When something has gone wrong there is a plan, named people and an order of work, rather than improvisation under pressure.
After an incident you can get back to normal operation, and you know how long that takes.
Normal operation is restored deliberately after an incident, and what happened feeds back into how things are run afterwards.
Changes to your systems are reviewed and tested by someone before they go live.
Changes to systems are approved, built and released through a defined route, so nothing reaches production without having been looked at.
You have thought about what happens if a key system goes down, and you have a plan or insurance for it.
The business has thought about what would interrupt it and what it would do about that, before being interrupted.
You know which outside companies touch your data, and you have checked that they handle it safely.
Suppliers with access to systems or data are assessed before being trusted and reviewed afterwards, because their weaknesses become yours.
You keep an eye on whether your systems have enough capacity, before they run out.
Demand on systems is measured and provisioned for, so the service does not fail simply by being used more than someone expected.
Your data is backed up, and the backups are protected as carefully as the original.
Backups and the means to restore from them exist, are maintained, and are protected as carefully as the systems they cover.
You have actually restored from a backup to check that it works - not just assumed it does.
Recovery is rehearsed, because an untested restore is a belief rather than a capability.
You know which of your data is confidential and where it lives.
Information the business has promised to keep confidential is identified as such and handled accordingly for as long as the promise lasts.
Confidential data is deleted when you no longer need it, rather than kept forever by default.
Confidential information is destroyed once the reason for holding it has ended, rather than kept indefinitely by default.
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.