To triage the first batch of failing compliance tests, do not fix them in order. Group them by cause, rate each by risk to customer data and by effort to fix, handle quick high-risk items first, assign owners and dates to the rest, and record every decision. A long red list is normal on day one.
TL;DR: Day one will look bad. That is the tool working, not your company failing. Use four steps: sort by cause, score by risk and effort, pick a first week plan, and write down what you decided. A few causes often explain many failures, so grouping saves time.
Definition box. Triage means sorting problems by urgency and effort so the right ones get fixed first. The word comes from emergency medicine, where the goal is the most benefit from limited time.
Why will the first scan look so bad?
When you connect a compliance tool, it checks every system against every rule at once. You have never seen all those results together. Many of the failures are not new problems. They are old, quiet gaps that nobody looked for.
It is also common for a few causes to produce many failures. One missing setting on an identity system might fail six tests. One expired connection might fail nine. Fixing the cause fixes the group.
So the right response is calm sorting. Panic leads to two bad habits: fixing the easiest items and ignoring the risky ones, or marking things as exceptions to make the screen green. Neither helps you in front of customers or an auditor. For the second habit, our guide on organizing exception evidence explains how to use exceptions properly.
How do you sort the list?
Step 1: Group by cause. Export the failing tests to a spreadsheet. Add a column called "cause" and fill it using these buckets, which also appear in why a compliance test fails when nothing changed:
- Connection problem: the tool cannot see the system.
- Real gap: the setting or process is truly missing.
- Scope problem: the test covers something it should not, such as a throwaway test repository.
- Missing record: the control runs but nobody has uploaded or linked proof.
- Test mismatch: the test checks something different from how you work.
Step 2: Score each group. Use a simple scale from 1 to 3 for each of two columns.
- Risk: 3 means it could expose customer data or let unreviewed code reach production. 1 means it is housekeeping.
- Effort: 3 means days of work or several people. 1 means minutes.
Step 3: Pick the first week. Start with high risk and low effort. Then high risk and high effort, which need a plan. Then low risk and low effort, which are quick tidy ups. Leave low risk and high effort for later, with a date to revisit.
Step 4: Record each decision. For each group, write the cause, the score, the owner, the due date, and the action: fix, exception, or change the rule.
What does the scoring grid look like?
| Low effort | High effort | |
|---|---|---|
| High risk | Do first this week | Plan this week, start next |
| Low risk | Quick tidy up, batch together | Schedule later with a review date |
Print this grid or paste it in your tracker. It helps people agree quickly.
How do you handle each cause?
Connection problems. Fix first. A broken connection hides the true state of many tests. After you fix it, expect the list to change, with some tests passing and some new real gaps appearing. Re-sort after the first fix.
Real gaps. Fix the setting or process. After the fix, rerun the test and keep the result with its date. If a gap has been open for a long time, write a short note saying when you found it and when you fixed it.
Scope problems. Adjust the scope if the item truly should not be covered, and write down why, who approved, and when to review it. Do not shrink scope to dodge a real risk.
Missing records. If the control runs but proof is missing, attach the proof, such as an export, a ticket link, or a signed policy. Our post on evidence register columns helps you keep track.
Test mismatches. If the test checks something different from your process, discuss with your auditor whether the test or the control needs to change. Do not edit a test just to turn it green.
Which failures involve software and vulnerabilities?
Some failing tests relate to software, for example "no unfixed critical vulnerabilities older than 30 days." These need extra care because vulnerability lists are long and many items do not matter in practice. Two ideas help:
- Check whether the vulnerable part of the library is actually used, which is reachability analysis.
- Check whether attackers are actively using the weakness, often called exploitability.
Sorting software findings this way keeps your list honest and short. The demo below shows the idea.
A worked example with invented numbers
The numbers below are invented for illustration.
A ten person company connects a tool and sees 48 failing tests on day one. The operations lead exports them and fills in the cause column.
| Cause | Count | Risk | Effort | Action |
|---|---|---|---|---|
| Expired connection to code host | 9 | 3 | 1 | Fix now |
| Identity system setting missing | 6 | 3 | 1 | Fix now |
| Repositories without review rule | 7 | 3 | 2 | Fix this week |
| Policies not approved | 8 | 2 | 2 | Schedule, two weeks |
| Throwaway repositories in scope | 5 | 1 | 1 | Adjust scope with note |
| Laptops not reporting | 6 | 2 | 3 | Plan, start next week |
| Test mismatch on backup wording | 2 | 1 | 2 | Ask auditor |
| Missing records for access review | 5 | 2 | 1 | Upload proof |
The totals are 9 plus 6 plus 7 plus 8 plus 5 plus 6 plus 2 plus 5, which is 48. By the end of the first day the company has fixed the 15 tests from the connection and identity causes. After the connection fix, the tool can see more, and 3 new real gaps appear, so the list is 36. After adjusting scope and uploading proof, it is down to 26. The remaining 26 each have an owner and a date.
Notice what did not happen. Nobody marked anything as an exception to hide it. Nobody backdated anything. The list went from 48 to 26 in a day because causes were grouped, and the rest has a plan.
What does a good first week look like?
- Monday: Connect systems, export the list, fill the cause column.
- Tuesday: Fix connection problems. Re-sort.
- Wednesday: Fix the quick, high risk gaps.
- Thursday: Assign owners and dates for everything else. Send each owner a short message with their items.
- Friday: Write a one page summary: what was found, what was fixed, what remains, and the dates.
The Friday summary is helpful to share with leadership. It shows control and progress.
Where does Safeguard fit?
Safeguard offers compliance and evidence automation that keeps dated test results, so you can show when each gap was found and when it was fixed. For software findings, its dependency scanning, reachability analysis, and exploitability signals help you decide which vulnerabilities to look at first. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the demo and look at how a finding is checked for whether it can really be used against you. Use the same thinking to rank software failures in your first batch.
Quick check
Should I fix the easiest tests first to show progress?
Not on their own. Start with high risk and low effort items. Quick tidy ups are fine to batch in, but do not leave risky gaps open while you polish easy ones.
Is it fine to mark failing tests as exceptions on day one?
Only when an item truly should not be covered, and with a reason, an approver, and a review date. Never use exceptions to turn the screen green.
What if an auditor will see the first red list?
A red list with a dated plan and a record of fixes is a normal story. What looks bad is a list that never shrinks or one that was edited to look better.
Last reviewed: 19 October 2026.
