The necessary ones make the site work. The others measure which pages help and which ads bring the people who need DM11. Your choice, and you can revisit it from the footer.
CIS CONTROLS
The controls are arranged by what tends to stop a real attack first, not by theme and not by what presents well. It is the most direct reference for anyone deciding where the next unit of budget goes, and it is the base that ISO 27001, SOC 2 and PCI DSS reuse when they arrive later.
The CIS Controls are the reference the market uses to measure a company's real security state, maintained by the Center for Internet Security. DM11 measures your current state, implements in the order that cuts risk fastest, and files the evidence. If a certificate is the destination, that evidence is the beginning of it, and the page for the standard you choose explains the rest of the route.
Who runs the implementation
ISO/IEC 27001 Lead Auditor certified by BSI
CISA, information systems auditing
Vulnerability management with a Qualys Certified Specialist
17 years of governance, risk and compliance
WHAT IT IS
The CIS Controls are a set of security controls published by the Center for Internet Security, currently at version 8.1, released in June 2024. There are 18 controls and 153 safeguards, and the trait that separates them from everything else is the order: they are not listed by theme, they are listed by what tends to stop a real attack first.
CIS splits the safeguards into three implementation groups. IG1 holds 56 and is defined as essential cyber hygiene: the minimum any company should have against the most common attacks. IG2 adds 74 for more complex operations, and IG3 another 23 for organisations facing sophisticated attackers. Starting at IG1 holds for a company of any size.
The 2024 revision introduced the governance function and aligned the structure with NIST CSF 2.0. The change acknowledges something implementers already knew: a safeguard with no owner does not survive its third month. Before that, the framework said what to do without saying who answers for keeping it working.
Worth settling the expectation early, because it shapes the plan. What the work produces is a measured picture of your state, with coverage per control and the evidence behind it. There is a credential called CIS Controls Accreditation, and it applies to the service provider who implements or audits rather than to the company being measured. Where your customer needs a document issued by a third party, ISO 27001 or SOC 2 is what answers that, and the work done here carries into that project intact.
The CIS safeguards appear, under other names, inside ISO 27001, SOC 2 and PCI DSS. Asset inventory, access control, logging, tested backups and vulnerability management are required by all three. The evidence produced here is the same evidence an auditor will ask for later, which is why CIS is so often the first year of a certification project.
WHO USUALLY NEEDS IT
None of them involves anyone demanding a certificate. Where a certificate is being demanded, the route is different, and the page for the standard in question explains which.
The company grew, IT kept up as best it could, and nobody ever stopped to look at the whole. There is no external requirement yet, and there is the correct sense that luck is not a strategy. CIS answers the question this company is actually asking, which is where to start, not which standard to follow.
Here the priority order is the product. With limited money, the difference between spending on IG1's 56 safeguards and spending on the tool a vendor pitched last week is large, and it only becomes visible when somebody measures before buying.
A company far from the requirements should not open a certification project on day one: the audit costs the same whether you are close or far. Implementing CIS first shortens the distance, with evidence the audit will accept later.
STORIES
We change our clients' names with the same confidentiality that will protect your company later. The names change; the pattern of the problems repeats. Where a client agrees, we give named references in a conversation.
Manufacturing
Every department kept a list of equipment and none of them matched. There were servers running that nobody could account for, and shop-floor machines on unsupported operating systems that appeared on no list at all, because maintenance looked after them rather than IT.
We started at the beginning, which in the CIS Controls is literally control number one: an inventory of assets and software. We established what actually exists, through scanning and through conversation, and set an owner for each item. Only after that did we discuss any protection.
The inventory turned up considerably more equipment than the official list showed, and most of the difference sat outside IT. The two cheapest safeguards in the whole project were switching off what no longer served a purpose and isolating what could not be updated.
Retail and e-commerce
The copy routine had run without failing for years, with a green report every morning. Nobody had ever restored anything into a test environment, and the board's perception was that the availability risk was covered because the report said so.
We tested the restore for real, against a clock, which is what the safeguard asks for and almost nobody does. We found that a critical database was being copied with the service running, without consistency, and that a full restore would take far longer than the operation could absorb.
The green report was accurate and useless: the copy existed and would not come back. Once the method was fixed and the restore timed, the company knew how long it would be down, which was the figure the board needed in order to decide how much to invest.
Professional services
For convenience, almost every user held administrative rights on their own machine, and three people in IT shared the same domain administrator account. There was no record of who did what with it, so any incident investigation would end in a draw.
We split day-to-day accounts from administrative ones, made privileged access individual and turned on logging. We removed local administrative rights in waves, starting where friction was lowest, with a defined process for the legitimate exceptions rather than informal ones.
The expected resistance never came: the genuine exceptions were few and were granted. The bigger gain was the logging, because from then on there was an answer to who did what, a question that previously had no answer available.
SELF-ASSESSMENT
Twenty-one questions about what the CIS Controls measure. The full result appears on screen, with a score for each front and the implementation group your profile calls for. There is no CIS Controls certificate, here or anywhere else, and we do not ask for your email to show the result.
The reading for each area, across the three result ranges. It is the same text emailed to those who identify themselves, published here for anyone who wants to understand what the score measures before answering.
Below 50
A low score here means the other scores in this diagnosis are worth less than they look: you answered about an environment whose extent nobody has confirmed. What is usually missing is not a tool, it is the reconciliation between lists that already exist in different places, IT's, finance's and purchasing's, because none of them is right on its own. The next step fits in two weeks: a network scan, a pass through the corporate card statement looking for cloud subscriptions, and an owner column next to each item. Only after that is it worth discussing buying protection, because any protection bought now will cover what you already know about.
50 to 79
In this band a list exists, and it ages faster than anyone can update it. The typical symptom is the item that came in around IT, the laptop of someone working from home, the equipment maintenance bought, the cloud service a department signed up for, and that is exactly the set nobody is updating or configuring. What closes the gap is tying the list to an automatic trigger, joining the network or an approved purchase, instead of depending on somebody to say something. On configuration, the cheap step is writing down the standard the technicians already repeat from memory, because memory does not survive holidays or a change of provider.
80 or above
With the inventory standing, the risk moves: it becomes the item that arrived after the last check and the configuration standard that exists on paper and is never checked against the real machines. It is worth measuring something almost nobody measures, the difference between what the list says and what the scan finds, and following that number month by month. If the difference grows, the process is leaking at the entrance, and that is where it gets fixed, not in the list. It is also worth checking whether the cloud is inventoried with the same care as the network, because silent growth today comes almost entirely from there.
Below 50
This is the score that shows up most often in a real incident. An environment with no second factor and no separation of administrative accounts demands no talent from an attacker: one password leaked from another service is enough. What is usually missing is not the technical decision, which is simple, it is someone with the mandate to hold the friction of the first weeks, because removing privilege bothers people who have worked that way for years. The next step, in the order that causes the least argument: second factor on email and on remote access, then an individual administrative account for the IT team, and only then the removal of local privilege, in waves, starting where friction is lowest. Service accounts and supplier accounts belong in that sweep and tend to be the forgotten ones.
50 to 79
Partly here almost always means the same thing: the second factor was turned on where it was easy, and the exceptions were never listed. The exception nobody wrote down is the one still open a year later, and it is the way in. The work is turning informal exceptions into exceptions with an owner, a reason and a review date, which also makes visible how many still exist. On the accounts side, the item usually missing entirely is the review of those that do not belong to a person: an old integration, a reporting robot, a user created by a supplier who has since left.
80 or above
In this band the control exists and maintenance is what decides. Three things degrade without warning: the service account created as a temporary measure, the supplier access still live after the contract ended, and the administrator who was given privilege to resolve an incident and kept it. A quarterly review comparing the list of privileged accounts against the list of who needs them today solves all three, and it takes less time than it seems. Record who reviewed and what was removed: that record is the evidence if you go for a certification later.
Below 50
What a low score here means, in practical terms, is that the company does not know how long it would be down and does not know whether it would come back whole. A backup never restored is a hypothesis, and a hypothesis only gets tested on the worst possible day. What is usually missing is not the copy, it is the test and the isolation: a copy reachable with the same network administration credentials is wiped along with everything else on the day of a ransomware attack. The next step is to choose a system that matters, restore it in a separate environment, time it and write the number down. That number is the information the board needs in order to decide how much to invest, and no green routine report delivers it.
50 to 79
Partly here tends to be one of two cases, and they call for different things. If the copy has come back at some point, but because of an incident and with no record, what is missing is turning the accident into a routine with a date and a recorded time. If the copy sits on another server or in the cloud under the same network credentials, what is missing is the isolation, and that is the item that most changes the outcome of a ransomware attack. On the sensitive data side, the frequent pattern is the shared folder the whole company has been able to see for years: finding out who accesses it today is usually faster, and more useful, than trying to classify everything at once.
80 or above
With a tested restore and an isolated copy, what remains is less obvious and more expensive to discover late: the scope. What tends to be missing from the restore list is something nobody classified as a system, the ERP database contracted in the cloud, the code repository, the mailbox, the configuration of the environment itself. It is worth doing the exercise backwards once: pick a scenario of total loss of a service and list what it would take to come back, instead of checking what is already in the backup. And it is worth reviewing who accesses the sensitive data as often as you test the restore.
Below 50
A low score here means the common attack needs nothing sophisticated: it uses a known flaw, with a published fix, in a program everybody has. What is usually missing first is not the scanning, it is automatic updates for what can already be automated, the operating system, the browser and the PDF reader, which on its own takes most of the risk on this front off the table. Then comes the list of what runs without receiving further updates from the manufacturer, which almost never exists and almost always includes old network equipment or a system that controls machinery. The concrete next step is to turn on automatic updates where there is no reason not to, and to write down the reason where there is one.
50 to 79
Partly here almost always means things are found and not closed. Finding a flaw is the easy, cheap part; the real cost is chasing the queue until the item disappears from the next report, and that is what separates a reduction in risk from a filed report. What is usually missing is a deadline by severity agreed with whoever operates, and someone with the explicit task of chasing it. If IT is outsourced, that agreement has to be in the contract: without it, fixing competes with the ticket of the day and loses every time.
80 or above
In this band the process works and the blind spot is usually what falls outside the scan. Network equipment, third-party systems hosted elsewhere, applications only the supplier touches and cloud environments rarely enter the same cycle as the machine estate, and the report looks good by omission. Check the coverage before celebrating the percentage: how many assets from your inventory appear in the latest scan, and which do not, and why. For what is out of support, what holds the score up is the recorded decision to replace, isolate or accept with a deadline, and not the list itself.
Below 50
There are two questions here, so the score is coarse, and even so it points at where the common attack actually comes in: email and the workstation. What is usually missing costs no new licence. The SPF, DKIM and DMARC records are domain configuration, and DMARC in observation mode stops nobody from writing while pretending to be your company, it only counts it afterwards. On the workstation side, what changes the game is having a central point that shows what was blocked, with a defined person to look at it: the value is not in the isolated block, it is in noticing that one machine blocks the same thing every week.
50 to 79
With only two questions, one partial answer already pulls the score down, so it is worth reading which of the two fell behind. If it was email, the typical case is DMARC published in observation only, which gives the feeling of protection without the protection: the route is to move to quarantine and then to reject, measuring what breaks at each step. If it was the workstation, the typical case is protection installed on every machine, with no console and no recipient for the alert, which produces logs nobody reads. In either case, the next step is to name who receives the alert and what that person does with it.
80 or above
A filter and the records in place cover the generic scam, and it is honest to say they do not cover the targeted one: a domain that looks like yours, a legitimate supplier account that has been compromised and a request to change bank details all pass any filter. In this band the gain comes from two things outside the tool: an easy route for a person to report when something feels wrong, and a business rule requiring confirmation through another channel before bank details are changed. It is also worth testing whether your endpoint protection reacts to real attack techniques, and not only to known malicious files, because that is where the difference between products shows.
Below 50
The consequence of a low score here only appears after the incident, and then it is final: with no logs kept off the machine, there is no way to know what was accessed, where they came in and when it started. That changes the cost of the incident, because without that answer the company is forced to assume the worst case in front of customers, insurers and authorities. What is missing tends to be simpler than people imagine: sending the logs of the main systems out of those systems, deciding how long to keep them and synchronising the machines' clocks, without which nothing lines up. On the plan side, the first step is one page saying who calls whom, with provider and legal phone numbers inside it.
50 to 79
Partly here tends to be a written plan that has never been exercised, or logs that exist on each machine and disappear along with it. A plan never exercised fails on the details only the exercise reveals: the out-of-date contact, the person who was on holiday, the decision nobody had the authority to take at two in the morning. The exercise is worth more than any improvement to the wording of the plan, and a two-hour conversation around a scenario already produces most of the learning. On logging, what is generally missing is a retention period: logs that roll over in seven days are no use, because the gap between a break-in and being noticed tends to be much longer than that.
80 or above
Centralised logs and an exercised plan leave the company able to respond. What is missing in this band is the link between the two: someone has to look at the logs before the incident becomes obvious. It is worth defining three or four situations that raise an alert, with an agreed recipient and response time, instead of keeping everything in wait for some future investigation. Check too whether the most recent exercise actually changed anything, a contact, a script, an access: an exercise that changes nothing was usually run to confirm the plan rather than to test it.
Below 50
The two questions in this domain are about people outside your technical control, which is why a low score here is not solved with a tool. On the people side, what is usually missing is continuity: one video at onboarding and nothing after does not change behaviour, and with no record of attendance there is no way to know who was left out. On the supplier side, the first step is the list of who accesses your systems, which almost never exists ready-made and tends to surprise by its size. Whoever looks after your IT normally holds the broadest access in the house, and that is not an accusation: it is the natural shape of the service they provide, and it needs to be written down somewhere.
50 to 79
Partly here usually means a generic contract with shared access on the supplier side, or training that happens without measurement on the people side. With suppliers, three items solve most of it: named access instead of a shared account, an expiry date that forces renewal, and a contractual obligation to tell you when they suffer an incident, which is the most forgotten clause of all. In training, what changes results is using examples from your own sector and measuring before and after, because without measurement there is no way to know whether the programme is doing anything. Neither front requires changing supplier or buying an expensive programme.
80 or above
In this band what holds the score up is the review, and it usually falls first on the supplier side: a contract signed three years ago with a clause nobody has reread, and access granted for a project that has already finished. A supplier leaving is the test equivalent to an employee leaving, and it is the most common silent finding when somebody finally checks. On the people side, the next level is not more training, it is measuring behaviour in a real situation. And it is worth treating whoever falls for it as someone who needs support rather than as a culprit, because a punitive programme makes people hide the click instead of reporting it, which is the opposite of what you need.
HOW WE RUN IT
The measurement is worth what it costs in honesty. Scoring a safeguard here is binary, met or not met, with evidence attached, because a subjective score drifts upward on its own and turns the report into a document that pleases and decides nothing.
The first two controls are inventories of assets and of software, and the order is not accidental: you cannot protect what you do not know exists. We map equipment, systems, cloud services and third-party access, with a defined owner for each item.
An inventory of assets and software, with an owner per item
Cloud services and third-party access mapped
A list of what is unsupported or has no owner
The target implementation group agreed with the board
Delivery milestoneInventory closed and reconciled against what IT had on record.
We score safeguard by safeguard, starting with IG1's 56, with evidence required for every positive answer. The result is a number, and the number exists to be moved later, not to decorate a presentation.
A score per safeguard, with evidence attached
Coverage by control and by implementation group
Gaps ordered by risk and by effort
An estimate of what is quick and cheap, kept separate from what needs investment
Delivery milestoneCurrent state measured and approved by the board, with no positive answer lacking evidence.
We implement alongside your team, following the order the measurement produced rather than the order of the numbering. Each safeguard gets an owner, a date, and a definition of what will serve as proof that it works, which is what separates it from a task marked done.
A plan with an owner and a date per safeguard
Implementation alongside your team or your IT provider
Evidence defined and filed for every safeguard closed
Adjustments to the IT contract where operations are outsourced
Delivery milestoneThe highest-risk safeguards closed, with the evidence filed.
We measure again using the same method, so the number is comparable. Where there is an intention to certify later, we organise the evidence in the form the chosen standard will ask for, so the work done here carries into the next project instead of being redone.
A second measurement, comparable to the first
A progress report for the board, free of jargon
Evidence organised in the form the intended standard expects
A maintenance routine defined, with who reviews and when
Delivery milestoneProgress demonstrated using the same method as the initial measurement.
HOW LONG IT TAKES
We do not publish a standard timeline, because a published timeline turns into a promise. The initial measurement is usually the short part; implementation is the part that varies. These are the three factors that move the clock most, and the first conversation already shows which one your company is in.
A company with a current inventory starts measuring in the first week. A company without one spends much of the start discovering what it has, and that discovery almost always turns up more equipment than the official list showed.
Closing IG1 is a project with a visible end. Moving on to IG2 adds 74 safeguards aimed at more complex operations, and IG3 is for organisations facing targeted attacks. Most companies gain more by closing IG1 entirely than by opening fronts across all three.
With an internal team, implementation moves at the pace of their calendar. With IT outsourced, a good share of the safeguards depends on the provider, and some require the contract to change. That conversation starts early in the project, because it tends to be the slowest one.
FREQUENTLY ASKED
The questions that come up in almost every first meeting, answered straight.
Not for your company. The Center for Internet Security maintains a credential called CIS Controls Accreditation, but it applies to the service provider who implements or audits the controls, not to the company being measured. If what you need is a document to send a customer, CIS alone does not solve it, and ISO 27001 or SOC 2 are worth looking at. What CIS delivers is your real state, measured, which is usually what is missing in order to decide the rest.
The document really is public and free, and we recommend downloading it. What costs is not the text. It costs to measure without fooling yourself, and self-assessment is where that breaks: every team scores itself above the truth, not out of bad faith, but because whoever built a control knows the intent behind it and stops noticing the gap. It also costs to prioritise 153 safeguards against your reality, and to implement while the team keeps the business running. If your company has the headcount to do that internally, do it, and bring us in for the measurement alone.
They are different documents and the confusion is common. The Controls say what the organisation needs to do at the level of process: inventory, control access, log, test backups. The Benchmarks are secure configuration guides for specific technologies, parameter by parameter, for an operating system, a database or a cloud service. The two complete each other: the Control says harden the configuration, the Benchmark says how.
It does, and it is one of the best uses of CIS. A good share of the safeguards corresponds to Annex A controls in ISO 27001, and the evidence produced here is accepted there. What CIS is not, and no honest reading pretends otherwise, is a management system: it has none of the context, leadership, internal audit and management review clauses certification requires. It shortens the technical route; it does not replace the certification project.
A measurement report, with coverage per control and the evidence behind it, not a certificate. It is worth checking what the customer actually asked for: most of the time they want to know whether you have basic security hygiene, and a report measured with method answers that better than a questionnaire filled in from memory. When they genuinely want a certificate, they will say ISO 27001 or SOC 2, and that is a different conversation.
Yes, and that is CIS's own definition: IG1 is essential cyber hygiene for any company, and IG2 and IG3 are built on top of it, not beside it. The classic mistake is jumping to advanced safeguards with the basics still open, because the advanced ones are more interesting to present. Common attacks still come in through the basics, and a large company has more surface for them to come in through.
A measurement against the first group's safeguards gives you a picture of the current state and the order of what to do first. It is the cheapest possible start, and it serves both the company that simply wants to stop being an easy target and the one that will certify later.
Center for Internet Security · versão 8.1, de junho de 2024 · accessed on
NIST, instituto nacional de padrões e tecnologia dos Estados Unidos · NIST CSWP 29, publicado em 26/02/2024 · accessed on
This page is informational and describes how DM11 reads and applies the sources above. It does not reproduce the text of any standard, does not replace reading the official document, and does not replace an audit, a certification, an independent assessment or legal advice. Where a standard requires formal assessment, it is carried out by an accredited body, auditor or assessor, always separate from whoever did the preparation.