63 controls · v4.0.1
The security standard the card brands hold you to if you take card payments, enforced through your acquiring bank rather than a regulator. How you validate depends on how you take payments and how many transactions you process: most small merchants complete a Self-Assessment Questionnaire rather than being audited by a Qualified Security Assessor, and which questionnaire applies depends on your setup, which your acquirer confirms. One limit is worth knowing before you start. Virtosic cannot determine your scope. Scope here follows the cardholder data environment - everywhere card data is stored, processed or transmitted, plus anything connected to it - and Virtosic does not observe how card data actually flows through your business. You draw that boundary; Virtosic works honestly inside it.
The rules for your network security are written down, kept current, and somebody is named as responsible for them.
The written rules and day-to-day procedures behind this requirement are current, in use rather than filed, and known to the people they affect, and each activity has a role accountable for it.
Your firewalls are set up to a written standard, changes to them are approved, and you have an up-to-date picture of how your network fits together.
Firewalls and the equivalent traffic-filtering controls are built to a defined configuration standard, changed only through an approved process, reflected in a current picture of the network and its data flows, and reviewed so that rules nobody needs any more are taken out.
Only the traffic your card systems genuinely need can reach them, and card data cannot quietly leave them for the internet.
Traffic reaching the systems that handle card data is limited to what the business genuinely needs, traffic leaving them is limited the same way, and card data is not permitted to leave for the internet from a system that has no reason to be sending it anywhere.
Where your network meets the internet or somebody else's network, something checks what is allowed through in both directions.
Where the organisation's network meets a network it does not control, traffic is filtered in both directions, and systems holding card data are kept off any path that would leave them directly reachable from the untrusted side.
Laptops that connect to the internet from home and to your card systems at work carry their own protection, so they cannot carry a problem in.
A device that can connect to an untrusted network and to the card environment - typically a laptop used from home and then brought back into the office - carries protection configured on the device itself, because the boundary controls never see the threat it walks in with.
How your systems should be set up securely is written down, kept current, and your team knows whose job it is to apply it.
The documented standards and procedures for configuring systems securely are kept current and actually used, and the people expected to apply them know that applying them is their job.
Your systems are set up from a known-good starting point, with the passwords they came with changed and anything you do not use switched off.
Every system in scope is built from a configuration standard that removes the passwords and accounts it shipped with, turns off services and functions nobody needs, and addresses the known weaknesses of that kind of system rather than leaving them to be found later.
Your wireless is not still running on the settings it came with, and its encryption is strong enough that nobody outside can read the traffic.
Wireless in scope has the settings it shipped with changed - encryption keys, passphrases and administrative access included - and uses encryption strong enough that the traffic cannot be read off the air by somebody sitting outside.
Your rules for looking after stored card data are written down, in use, and someone is accountable for each part of them.
The written procedures for handling stored card data are current and in use, reach the people who actually handle that data, and name who is accountable for each part of the work.
You keep card data only as long as you have a reason to, and something actually goes and deletes it when that reason runs out.
Card data is held only while there is a business, legal or regulatory reason to hold it, with retention periods decided in advance and a process that actually goes and finds the data once those periods pass. Data never stored is data never breached.
The security code on the card, the PIN and the stripe data are never kept once the payment has gone through, not even for a moment afterwards.
The data used to authenticate a card at the moment of the transaction - the full magnetic stripe or chip data, the verification code printed on the card, the PIN and its block - is not held once the transaction has been authorised, however briefly it was needed to complete it.
Card numbers on screen are hidden except for the few people who genuinely need to see them in full, and cannot simply be copied elsewhere.
Where a card number appears on a screen or a printout it is masked, so that only people with a documented business need see it in full, and the ability to copy it out to somewhere unprotected is deliberately restricted.
Card numbers you store are scrambled, shortened or swapped for a token, so a stolen copy of the file is not a list of usable card numbers.
Wherever a card number is stored it is rendered unreadable - by strong encryption, by truncation, by replacing it with a token, or by a one-way hash of the whole number - so that a stolen copy of the storage is not a stolen list of card numbers.
The keys that unscramble your stored card data are protected and kept apart from the data, because a key left beside the lock is not a lock.
The cryptographic keys that make stored card data unreadable are themselves protected, held in as few places and by as few people as possible, and kept apart from the data they unlock. A key stored beside the data it protects protects nothing.
You have written steps for how encryption keys are created, handed out, stored, replaced and retired, and those steps are the ones you follow.
Key management is written down and followed across the entire life of a key: how it is generated, distributed and stored, when it is replaced, how it is retired when there is reason to think it has been exposed, and who is prevented from substituting one.
How you protect card data while it travels across the internet is written down, kept current, and assigned to someone.
The documented procedures for protecting card data as it crosses networks the organisation does not control are current, in use and understood, with the activities they describe assigned to roles.
Card numbers sent over the internet are strongly encrypted with a valid certificate, and never sent by email, text message or chat.
Card numbers sent across open or public networks are protected by strong cryptography, correctly configured and using certificates that are valid and trusted, and are never sent through messaging technologies such as email, text or chat that give the sender no protection at all.
Your rules for keeping malware off your systems are written down, followed rather than filed, and owned by someone.
The written procedures covering malicious software are current, followed rather than filed, and known to the people they affect, with each activity assigned to a role.
Your computers run something that stops malware, and where you decided a system does not need it, you wrote down why and you revisit that.
Systems that can be affected by malicious software run a mechanism that detects and deals with it, and where a type of system is judged not to be at risk that judgement is written down with its reasoning and revisited, rather than assumed once and forgotten.
Your malware protection is always on, keeps itself up to date, keeps logs, and an ordinary user cannot switch it off.
The protection runs continuously, keeps itself current, produces logs somebody can look at, and cannot be switched off or altered by an ordinary user. Protection that a person can silently disable is protection nobody can rely on.
Something filters phishing attempts before they reach your team, rather than the whole defence resting on people spotting a good fake.
Mechanisms stand between staff and phishing attempts, so that the defence does not rest entirely on somebody recognising a convincing message on a busy afternoon.
How you keep your systems and software secure is written down, kept current, and the people who build them know their part in it.
The documented procedures for building and maintaining secure systems and software are current and in use, and the people who develop or maintain systems know which parts of that work are theirs.
Software written for you is built by people trained in secure coding and reviewed by someone else before it goes live.
Software written for the organisation, whether in-house or to order, is built by developers trained in secure coding for the languages they use, reviewed before it is released, and guarded against the common classes of flaw for its platform.
You keep track of newly found weaknesses in the software you run, rank them by how dangerous they are to you, and fix the serious ones quickly.
Newly published weaknesses in the software the organisation runs, including the components inside its own software, are watched for, ranked by how dangerous they are in this environment, and patched on a schedule that treats the critical ones far more urgently than the rest.
Your public website is checked or shielded against attack, and you would know if a new script appeared on the page where customers type card details.
Web applications reachable from the internet are either reviewed regularly for weaknesses or shielded by an automated control in front of them, and the scripts running on a payment page are authorised and inventoried so that one nobody approved cannot appear unnoticed.
Changes to your systems are recorded, approved, tested and reversible, and you do not test using real card data.
Changes follow a process that records what is changing and why, has somebody with authority approve it, tests it, and can put it back, with development and test work kept apart from live systems and live card data kept out of test.
The rules for who may reach card data are written down, kept current, and someone is responsible for keeping them that way.
The written procedures governing who may reach card data and on what basis are current, in use and known, with responsibility for each activity allocated to a role.
Each person gets the least access their job needs, someone with authority approves it, and you check periodically that it still fits.
Access comes from a defined role carrying the least privilege that role needs, is approved by somebody with the authority to approve it, and is reviewed periodically so that it still matches what the person actually does.
A system enforces who can reach what, and its answer is no unless somebody deliberately gave that person access.
Those access decisions are enforced by an access control system covering every component in scope and set to deny by default, so that reaching something follows from a deliberate grant rather than from the absence of a rule.
How people prove who they are on your systems is written down, kept current, and owned by someone.
Identifying users and proving who they are is governed by written procedures that are current, in use and known to the people they affect, with named roles behind each activity.
Everyone has their own login, leavers lose theirs, unused accounts are switched off, and a supplier's account exists only while they are working.
Each person has an identifier of their own so that actions can be traced to a human being, accounts are removed when somebody leaves, accounts left unused are disabled, and an outside party's account exists only while that party is working.
Passwords on your systems are long enough to be hard to guess, protected where they are stored, and repeated wrong guesses lock the account.
Authentication factors are strong enough to resist guessing and are protected wherever they are stored or sent: passwords meet a defined strength, are replaced when there is reason to think one has been exposed, and repeated failed attempts lock the account rather than being tolerated indefinitely.
Getting into your card systems, or getting in from outside, takes more than a password - a code or a key as well.
More than one kind of authentication factor is required to get in from outside the network, to use administrative access, and to reach the environment that handles card data at all.
Your second-factor setup cannot be skipped or worked around, and nobody holds a quiet exemption from it.
The multi-factor system itself is configured so that it cannot be bypassed: the factors are independent of one another, access needs all of them rather than any one, and no account is quietly exempted without a documented reason.
The accounts your software uses are managed too, with their passwords kept out of scripts and changed rather than set once and forgotten.
Accounts that belong to software rather than to a person are managed deliberately: a human using one interactively is restricted and justified, the passwords they hold are not written into scripts or configuration files, and they are changed rather than left as set on installation day.
Your rules for who can physically get to card data are written down, kept current, and someone is responsible for them.
The written procedures for controlling physical access to card data are current, in use, and known to the people who work where that data is handled, with responsibility for each activity allocated.
You control who can walk into the places card data is handled, and a visitor cannot just plug into a socket in your reception.
Entry to the places where card data is handled is controlled and watched, network sockets and wireless equipment in areas the public can reach cannot simply be used by whoever walks up to them, and any recordings of sensitive areas are protected and kept.
People get physical access because it was approved, visitors are told apart from staff and escorted, and you can see later who came in.
Physical access is authorised before it is granted and withdrawn when the reason for it ends, staff and visitors can be told apart on sight, visitors are escorted where it matters, and a record shows who came in and when.
Paper and drives holding card data are stored securely, tracked if you send them anywhere, and destroyed so nobody can put them back together.
Paper and electronic media holding card data is classified by sensitivity, stored securely, tracked when it is sent anywhere, approved before it moves, and destroyed at the end so thoroughly that it cannot be put back together.
You have a list of your card machines, you check them for signs of tampering, and your team knows to report one that looks wrong.
Card-reading terminals are inventoried, inspected on a schedule for signs of tampering or of having been swapped for a lookalike, and the staff who use them every day are trained to notice and report a device that is not right.
How you log and watch access to your card systems is written down, kept current, and assigned to someone.
The documented procedures for logging and monitoring access are current, in use, and known to whoever operates them, with each activity assigned to a role.
Your systems keep logs showing who did what, when, from where and whether it worked, including everything done by people with admin rights.
Logs are produced across the systems in scope and record enough to reconstruct what happened - who acted, what they did, when, from where, whether it worked and what it touched - with administrative action and every access to card data among the events captured.
Your logs cannot be edited or deleted by the person they are recording, because they are written somewhere separate straight away.
Logs can be read only by people who need them and are protected from being altered or deleted, including by the person whose actions they record - which in practice means writing them promptly somewhere the source system cannot reach back into.
Someone or something actually reads your logs on a schedule and follows up what looks wrong, rather than only storing them.
Logs are actually read rather than only collected, with the most security-relevant ones reviewed daily and the rest on a rhythm the organisation sets from risk, and anything out of the ordinary is followed up rather than noted.
You keep enough log history to investigate something you only find out about months later, with the recent part still quick to search.
Log history is kept long enough to investigate an intrusion discovered months after it began, with the most recent stretch immediately available to search rather than only recoverable from an archive somebody has to restore.
All your systems agree on the time, so logs from different machines can be lined up in order after something goes wrong.
System clocks are synchronised to a common, controlled time source and protected from casual change, because logs from machines that disagree about the time cannot be put into order after an incident, which is when the order is the whole point.
If your firewall, logging or malware protection quietly stops working, you find out promptly rather than discovering it months later.
When a security control stops working - the firewall, the logging itself, the malware protection, the monitoring - the failure is noticed promptly, reported, and put right, with a record of what was exposed for as long as it was down.
How and when you test your security is written down, kept current, and assigned to someone rather than left to memory.
The written procedures for testing the security of systems and networks are current, in use and known, with the activities assigned to roles rather than left to whoever happens to remember them.
You check periodically for wireless access points nobody approved, which still matters if you do not use wireless yourself.
The organisation knows what wireless is present where it operates, tests periodically for access points nobody authorised, and has a response ready for finding one. This applies whether or not wireless is used deliberately, because the point is the access point somebody else plugged in.
You scan inside and outside your network on a schedule, fix what comes back, and scan again to show the fix actually worked.
Internal and external scans run on a set rhythm and after significant change, findings are ranked and fixed, and the scan is repeated to show the fix worked, with the external scanning carried out by a scanning vendor the industry has approved.
Someone qualified and independent tries to break in on a schedule, you fix what they find, and they check that the fix holds.
Somebody qualified and organisationally independent tries to break in, to a defined method, from outside and from within, on a schedule and after significant change; what they exploit is corrected and retested, and where network separation is relied on to keep the scope small, that separation is tested too.
Something watches for an intrusion at the edge of your card systems and for unexpected changes to important files, and tells a person.
Traffic at the edge of the card environment is watched for intrusion with a person alerted when something is seen, and critical files are watched so that an unexpected change to one is noticed at the time rather than found during the investigation.
You would find out if the page where your customers type their card details was quietly changed to send those details somewhere else.
What actually reaches the customer's browser on the page where they type their card details is monitored, so that an unauthorised change - a skimming script added somewhere upstream, a header quietly altered - is detected and acted on.
You have an overall security policy, signed off by whoever runs the business, kept up to date, and your team knows what is in it.
There is an overall information security policy, approved by management, that sets the direction for protecting the organisation's information, is reviewed and kept current, is understood by the people it governs, and comes with security responsibilities assigned to named roles.
There are approved rules for how your team may use laptops, phones and memory sticks, and where card data is allowed to go.
There are approved rules for how staff may use the technology they are given - laptops, phones, removable storage, remote access - covering what may be done with each and where card data is and is not allowed to go.
You work out in writing what could go wrong for your card systems, including anywhere you chose the timing yourself, and act on what you find.
Risk to the card environment is identified and evaluated deliberately and in writing, including in the places the standard leaves to the organisation's own judgement: how often a control is performed, technology approaching the point where nobody supports it, and cryptography that is weakening with age.
Somebody senior owns card security, and the day-to-day work gets checked through the year rather than only when an assessor turns up.
Overall responsibility for protecting card data sits with executive management, and the work of confirming that people are still doing what the procedures say is performed periodically by somebody other than the person doing it. Every specific requirement under this heading falls on service providers rather than on merchants.
You have written down which systems are in scope and how card data moves through your business, and you check that picture is still right.
There is an inventory of the components in scope and a record of how card data flows through the business, and the scope is confirmed as still accurate on a schedule. Everything else rests on this: a control applied to the wrong boundary protects nothing.
Your team is trained on security when they join and again regularly, on material that gets updated as the threats change.
Security awareness runs as an ongoing programme rather than an induction: people are trained when they join and again at intervals, the material is refreshed as the threats change, and it covers what to do with a suspicious message and how card data is handled here.
You check the background of people before giving them access to card data, as far as the law where you are allows.
People who will be given access to the card environment are screened before they get it, to the extent the law where they work allows, so that trusting somebody with card data is a decision rather than a default.
You have a list of the outside companies that touch your card payments, a written split of who does what on security, and you check on them.
The organisation keeps a list of the providers that hold card data for it or could affect the security of it, checks their standing before engaging them, agrees in writing which security duties belong to whom, and monitors that those duties are still being met.
If you handle card payments for other businesses, you owe them a written acknowledgement and the evidence they need for their own checks.
A provider handling card data on behalf of other businesses acknowledges in writing that it is responsible for the data it holds, and gives those customers the information they need to assess their own position. This falls on service providers rather than on merchants.
You have a plan for a suspected card data breach that says who does what and who you must tell, and you have tested it.
There is an incident response plan that can be acted on immediately: who does what, how the acquirer and the payment brands get told, how containment and recovery proceed. It is tested and revised, and the people named in it are available and trained to play their part.
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.