Weight and effort are different axes, and confusing them is expensive
The scoring methodology behind a Level 2 assessment assigns each requirement 5, 3, or 1 point: forty-two carry five points, fourteen carry three, and the remaining fifty-four carry one. That weighting reflects how much damage the requirement's absence could do. It says nothing whatever about how hard the requirement is to implement, and the two axes cross in ways that decide whether a remediation budget is well spent.
There are five-point requirements you can satisfy in an afternoon and one-point requirements that need a platform you do not own. Sequencing by points alone produces a good score and an environment with a hole in it. Sequencing by ease produces visible progress and a stalled score. What you want is the intersection: the requirements that are both heavily weighted and genuinely hard, started first, because they are the only ones with a lead time.
Before any of that, a piece of arithmetic worth knowing. The six requirements that can never sit on a plan of action — the two access control requirements covering external systems and publicly accessible content, the system security plan requirement, and the three physical protection requirements covering visitor escorting, physical access logs and physical access devices — are gating regardless of your total. Confirm those six before you sequence anything else, because a single failure among them removes the conditional path entirely.
You are probably here because
- You have a gap list of sixty items and no idea what to do first
- Someone gave you a budget number and you need to know what it buys
- You passed a self-assessment last year and want to know what will have decayed
- You are trying to work out whether this is a project or a permanent job
The four-bucket section is the useful part. The fourth bucket is the one that decides whether you are still compliant in eighteen months.
Four kinds of work, wearing one uniform
Every one of the 110 falls into one of four categories of effort, and the category tells you who does it, what it costs, and whether it stays done.
| Bucket | What it takes | Rough share of the 110 |
|---|---|---|
| Written down | A policy or procedure that is accurate and followed. Cheap in money, and worthless if the document describes a practice nobody performs | Roughly a quarter |
| Turned on | A configuration change in something you already run: a policy setting, a group membership, an encryption toggle, a retention period | Roughly a third |
| Bought or built | A capability that does not exist yet — centralized logging, vulnerability scanning, an identity platform that can enforce what is required | Roughly a fifth |
| Done forever | An activity on a recurring cadence, with evidence each time. Log review, access review, scanning and remediation, incident exercises, plan updates | Roughly a fifth |
Money and calendar time live in the third bucket. Risk lives in the fourth. Firms consistently plan for the third and are surprised by the fourth, which is why so many environments pass an assessment and then drift out of compliance without anyone noticing.
The handful that consume the budget
In most small and mid-size estates, the same short list accounts for the majority of the effort. None of these is exotic. All of them touch either identity, cryptography, or observability — the three areas where a general-purpose business network is usually furthest from what the standard asks.
Multifactor authentication, everywhere it is required. Most firms have it on remote access and on administrator accounts. The requirement reaches further than that, which is why the methodology gives partial credit for the common halfway state: implementing it for remote and privileged users but not for the general user loses three points instead of five. The work is rarely the technology. It is the machine on the shop floor with a shared login, the service account nobody can identify the owner of, and the application that predates modern authentication.
FIPS-validated cryptography. This is the requirement that most often surprises people, because encryption is usually already on. The standard asks for validated modules, and the methodology again distinguishes the halfway state: encryption in use but not FIPS-validated loses three points rather than five. Getting this right is often a matter of enabling a validated mode in products you already own, and occasionally a matter of replacing one that cannot do it. Check every place CUI is encrypted — disks, databases, backups, transport, and any file-level tool — and confirm the module rather than the marketing.
Audit logging that someone actually reads. The audit family asks for records to be created, retained, protected from modification, tied to individual users, and reviewed. Creating logs is easy. Centralizing them so they survive the compromise of the machine that made them takes a platform. Reviewing them takes a person and a cadence, and that is the part that quietly does not happen.
Protecting CUI at rest and in transit. Straightforward in a modern cloud estate, painful on a file server that has been running since before anyone thought about it, and genuinely fiddly for backups, which are frequently the last copy anyone gets around to encrypting.
Baseline configurations and inventory. You cannot claim a baseline without knowing what is on the network. Many firms discover during this requirement that they do not have a reliable inventory, and that discovery is worth the price of the whole exercise independent of compliance.
Vulnerability scanning and, more importantly, remediation. Buying a scanner is one purchase order. Establishing that findings are triaged and fixed on a defined cadence, with a record, is a standing operational commitment that touches every team.
Incident response that has been exercised. A plan is cheap. The requirement to test the capability means the plan has to be run at least as a tabletop, with a record of what happened. And separately from the 110, the safeguarding clause requires reporting cyber incidents to the Department within 72 hours of discovery through the government's reporting portal, which needs a specific type of certificate obtained in advance. Getting that in place before an incident is a two-hour task; getting it during one is a disaster.
The system security plan. It is not documentation about the controls. It is a scored requirement in its own right, and it is one of the six that can never be deferred. A plan that describes an environment you no longer run is worse than a short one that is true.
Effort by family, typical mid-size estate — our read
Our judgement of relative implementation effort, not a survey. A firm already running a modern identity platform and centralized logging inverts the top three.
The ones that are nearly free, if you have modern infrastructure
A fair share of the 110 is already satisfied by an estate that was built in the last few years, and it is worth claiming that rather than paying twice.
- Session lock and session termination — standard endpoint policy
- Least privilege and separation of duties — role assignment you probably already do, needing documentation more than change
- Unsuccessful logon attempt limits and login banners — settings
- Malicious code protection and signature updates — any current endpoint product
- Security alert and advisory monitoring — a subscription and a named reader
- Personnel screening and access removal on termination — an HR process, written down and evidenced
- Visitor escorting and physical access logs — a book at the front desk and a rule that is enforced
- Awareness training — an annual module plus role-specific instruction for people who handle CUI
The reason to inventory these first is not just savings. It is that the easy ones generate the documentation habit you will need for the hard ones, and they let you produce a truthful score early instead of waiting until remediation is finished.
The requirements that pass once and fail later
This is the section we would keep if we had to throw the rest away. A certification is valid for three years with an annual affirmation in between, and the requirements that break in that window are always the recurring ones.
Audit review. The logs keep flowing. The review stops after the third month, because nothing happened in the first two and the person doing it got busy. Fix: a fixed cadence, a named owner, a short written record of each review even when the answer is nothing of note, and an alert if the review does not happen.
Access review. People change roles. Contractors finish. The account list drifts from the authorization list, and the gap widens quietly. Fix: a quarterly reconciliation between the authorized-user list and what the directory actually contains, with the differences resolved rather than noted.
Vulnerability remediation. Scanning continues because it is automated. Remediation slips because it is not. Fix: a defined timeline by severity, and a monthly report showing what aged past it and why.
Configuration drift. The baseline was accurate the week it was written. Then someone needed an exception for a legacy application. Fix: exceptions in writing with an expiry date, and periodic comparison of running configuration against the baseline.
The plan itself. Environments change constantly and system security plans do not, because updating them is nobody's favourite afternoon. Fix: make a plan update part of the change process for anything inside the boundary, so it moves with the environment rather than in an annual panic.
These five are also the ones an assessor probes hardest, because they distinguish a firm that implemented from a firm that prepared. The question is rarely “do you review logs.” It is “show me the last three reviews,” and the dates on those records tell the whole story.
Evidence is not a separate task
The most common structural mistake we see is treating evidence collection as a phase that happens after implementation. It never works, because the evidence an assessor wants is contemporaneous. A screenshot taken the week before an assessment demonstrates that the setting is on today. A ticket from four months ago demonstrates that the practice exists.
So build the evidence trail into the operating routine from the first week. Each recurring activity should leave an artifact automatically: a ticket, an export, a dated record in a shared location, a report emailed to a distribution list. If producing evidence requires someone to remember, it is on the same footing as the boundary crossings that rely on memory, and it will fail the same way.
- Remediating in control-number order, which spends the same money for a worse score and a worse environment
- Buying a tool for a requirement that is really a policy, and buying nothing for one that genuinely needs a platform
- Treating multifactor as done because remote access has it
- Assuming encryption satisfies the cryptography requirement without checking module validation
- Writing a system security plan describing an intended environment rather than the running one
- Planning for the one-time work and not the recurring work, which is where certifications are actually lost
- Collecting evidence at the end, when what is wanted is a record made at the time
What we would do first, with no budget at all
If a firm had nothing to spend this quarter and wanted the largest honest improvement, this is the order. All of it is configuration, process, or attention.
- Check the six requirements that can never be deferred. An afternoon, and it changes the plan if any fails
- Extend multifactor to every account that can take it, and write down the ones that cannot with a date
- Confirm which encryption is validated and enable a validated mode where the product supports one
- Reconcile the account list against the authorized-user list and remove what does not belong
- Turn on centralized log collection for the systems inside the boundary, even at short retention to start
- Start the review cadences now, so the third assessment-relevant record exists when it is needed
- Write the system security plan honestly, marking what is not yet implemented rather than describing intentions as facts
Bottom line
The 110 are not a wall. They are four different kinds of work with one label on them, and the plan that works separates the writing from the configuring from the buying from the doing-forever. Sequence by the intersection of weight and lead time. Claim the cheap ones early so your score is truthful before remediation finishes. Put the recurring activities on a cadence with automatic evidence from the first week, because those are what fail between assessments.
And do the arithmetic before the shopping. A remediation plan whose first three line items are products is usually a plan written by someone selling products.
Frequently asked questions
Check the six that can never sit on a plan of action, because a failure among them removes the conditional path no matter what your total is. Then work the requirements that are both heavily weighted and slow to implement, since those are the ones with lead time — identity, cryptography, centralized logging. Cheap, high-weight items can be done at any point; they are not the constraint.
The requirement asks for validated cryptography when it is used to protect CUI, and the scoring methodology treats the halfway state explicitly: encryption employed but not validated loses three points instead of five. Practically, check every place CUI is encrypted — disks, databases, backups, transport, file-level tools — and confirm the module and mode against the product's own documented validation rather than a summary.
Roughly a quarter can be satisfied with an accurate policy or procedure, which is cheap in money and not free in attention: a document describing a practice nobody performs is a finding rather than a control. Another third are configuration changes in systems you already run. The remaining portion needs either a capability you do not own or a recurring activity you have to sustain, and that is where the real cost sits.
Almost always the recurring requirements: audit review, access review, vulnerability remediation, configuration drift, and the system security plan itself. Each of them passes on the day it is set up and decays quietly afterward. Fix them with cadence, a named owner, and evidence produced automatically, then check the dates on your own records the way an assessor will.
Some of it, and it is often sensible — log review and vulnerability management are natural candidates. Two conditions apply. The provider's platform becomes part of your assessment scope because it protects your environment. And the responsibility does not transfer: your affirmation is signed by your official about your environment, so you need the records in your own hands, not only in the provider's console.