The report has been sitting in the shared folder for three weeks, and the company is exactly where it was before. That is the normal outcome after a security assessment, and the report is rarely the reason.
An assessment produces findings. An IT security remediation plan does not follow from them by itself, because the two documents answer different questions. The report says what is not in order at your company. The plan says who does what by when, and what you deliberately leave open. The second part is the uncomfortable one, and it is the reason reports stay untouched.
Why the "critical" column is not your priority list
In most cases the severity ratings in an assessment report come from CVSS, the Common Vulnerability Scoring System. It is a useful system, it simply answers a different question than yours. FIRST, the organisation behind the standard, writes in the CVSS 4.0 specification: "The Base Score reflects the severity of a vulnerability according to its intrinsic characteristics which are constant over time." The value describes the vulnerability itself, regardless of where it sits.
That is why the same document points out that the work continues at the receiving end: "Consumers of CVSS should enrich the Base metrics with Threat and Environmental metric values specific to their use of the vulnerable system to produce a score that provides a more comprehensive input to risk assessment specific to their organization." And FIRST lists what falls outside its own scoring frame: regulatory requirements, the number of customers affected, monetary losses, danger to life or property, reputational damage. Those factors are "outside the scope of CVSS".
In plain terms: the number in the report is the view from outside. What it means for you is decided by your business, and that part appears nowhere in the document.
We see the pattern in assessments regularly. A high severity finding sits on a test system that holds no customer data and that two people know about. A medium severity finding sits on the one server that order processing runs on. Work the list from top to bottom and you start with the test system. That is not a mistake by the assessors. It is the point where the report ends and your work begins. More on what a security assessment delivers and what it does not.
The three questions that turn findings into a plan
You do not need a methodology with a name. You need three passes through the same list.
What stops the business?
Go through the findings and ask of each one what happens if this system stands still for a day or its data leaks. Not in theory. In your own terms: can we still deliver and still invoice. Anything that produces a clear no belongs at the front, even if the report says "medium".
Which single change clears several lines?
In every report we see, findings hang together in groups. Overly broad permissions produce half a dozen findings in different places. Missing multi-factor authentication shows up three times, at remote access, in mailboxes and on administrative accounts. Solve one thing properly and several lines disappear. That is the cheapest progress the plan has to offer, and the list does not show it, because reports are sorted by system and not by cause.
The most common case of this kind is permission groups that everyone who ever needed access has ended up in over the years. Such groups produce findings in the file storage and in the business applications at the same time. Reviewing the memberships therefore clears several lines at once, and it costs working hours instead of licences. The report still shows it as three or four separate findings, because the assessment looks system by system.
What costs nothing but a decision?
Part of the findings can be closed with a decision: a setting that is already included in your existing licence, an account nobody needs any more, a rule that was never written down. In our experience this pile is larger than the management team expects, and it is the reason an IT security remediation plan is not automatically an investment request.
Three passes, and the list turns into an order of work. What is left after that costs money or time, and management can decide on it cleanly.
How an IT security remediation plan survives week three
A plan that stalls almost always looks the same: a table with several dozen lines where "IT" is the owner everywhere and the deadline is "ongoing". Neither is an assignment, it is a polite form of nobody and sometime.
Five entries per line are enough, and none of them is optional:
- the measure in one sentence, in the language of the people doing it
- a person by name, not a department
- a date
- the expected effect, meaning which findings it closes
- the decision: implement, postpone with a reason, or deliberately accept
The last column changes the most. A remediation plan without accepted residual risks is a wish list, because hardly anyone works through a list of that length completely. If instead you record that you will not touch three findings this year because the system in question is being replaced in the summer, that is a decision with a date and a reason. It holds up in an audit, and it holds up in front of the board of directors, which in a serious incident has to show that it knew the risks and decided deliberately.
A rhythm belongs with it. Half an hour a month in which someone goes through the lines and asks three questions: done, blocked, or no longer relevant. No project office, no status report to three distribution lists. In our experience this monthly slot decides more about the outcome than the quality of the report everything started with.
One thing needs clarifying before the plan is distributed: which lines does IT decide on its own, and which ones need management? Anything touching money, workflows or commitments to customers is not an IT decision, even when it sounds technical. If that line is not drawn, the effective measures are exactly the ones that stall. The person assigned to the work does not have approval, and does not ask for it either, because the line is assigned to them.
How long should implementation take?
An IT security remediation plan runs over one year in our engagements. Whatever can stop the business goes into the first three months. The group solutions that clear several findings at once run until roughly mid-year. Everything else gets a date or is recorded as residual risk. Plan beyond that and you are planning for an environment that will no longer exist.
More important than the duration is what the deadlines hang on. A date set out of nowhere slips. A date tied to a licence renewal or a maintenance window usually holds. So it pays to couple the measures, while writing them down, to dates that are in the calendar anyway.
A report that is a year old describes a different company than today's. If the list is still half open after twelve months, a decision comes first: which of those lines still apply at all.
What does not belong in the plan
Part of the work is not doing things. Four items we cut regularly in client engagements.
One tool per finding. The reflex makes sense, because every line looks like a hole that a product fits into. In the end you have seven overlapping subscriptions that nobody operates. How to merge them instead is in our post on consolidating security tools.
The follow-up audit before anything has been implemented. A second assessment confirms the same findings and costs the same again. The right time for it is after implementation.
Findings on systems you are retiring anyway. If the retirement is scheduled, this belongs in the "deliberately accepted" column and not in the work.
The hunt for completeness. An assessment report is a snapshot and not a complete picture of your operation. What we run into in practically every assessment is collected in what we find in every IT audit. Solving those findings first is worth more than hunting for the last entry on the list.
If, reading this, you notice that your report was never put into an order of work: that step is part of our security assessment with implementation support. The report is the smaller part of the job.
Next Friday afternoon
Take the report sitting at your company and one hour. Go through the findings once with the question of what stops the business, and mark the five where the answer is uncomfortable. A first IT security remediation plan needs no more than five lines. Write a name and a date behind each one, and note underneath what you are deliberately leaving open this year.
That is done in an hour and gets you further than the complete list nobody touches.
One question remains, and we often cannot answer it cleanly until the second conversation: who in your company is allowed to decide that a risk stays open? If you are unsure about the answer, that is the gap, not the technology.
If you want to turn an existing report into an order of work that holds, talk to us. A first conversation is free of obligation.
Frequently asked questions
How do I prioritise the findings from a security assessment?
Not by the severity column. Go through the list three times: what stops the business if it fails or leaks? Which single change clears several findings at once? What can be closed with a decision instead of a budget? Those three passes produce the order of work.
What belongs in an IT security remediation plan?
Five entries per line: the measure in one sentence, a person by name rather than a department, a date, the expected effect including the findings it closes, and the decision. Implement, postpone with a reason, or deliberately accept as residual risk.
How long should implementation take after an assessment?
One year is the frame we work with in client engagements. Whatever can stop the business goes into the first three months, group solutions until roughly mid-year, everything else gets a date or is recorded as residual risk. Deadlines hold better when tied to licence renewals or maintenance windows.
