Security Program Workspace

Security Controls Tracker: Status, Owners, and Evidence

Most small security programmes are tracked in a spreadsheet that answers one question — is this control done? — and three questions it cannot answer: who owns the ones that are not, when did they say they would be, and what evidence exists for the ones marked done. This workspace tracks a 12-control baseline with a status, an accountable owner, a target date, and an evidence reference on every line, and turns that into a ranked remediation queue rather than a colour-coded list.

It runs entirely in your browser. No account, no upload, and nothing about your control posture leaves the device — which is the appropriate handling for a document that is, in effect, a list of your organisation’s weaknesses.

Six Statuses, Because Done Is Not Binary

The usual red-amber-green scheme collapses the most important distinction in control assurance: the difference between someone saying a control is implemented and someone independently confirming it. Each control carries one of six statuses, and each contributes a different weight to coverage:

The gap between implemented at 0.8 and verified at 1.0 is deliberate and is the most useful number on the page. A programme that is 100% implemented and 30% verified is in a materially different position from one that is 100% verified, and it is exactly the position that produces unpleasant surprises during a first audit or a real incident. Backups marked implemented because the job reports success, with no restore ever tested, is the canonical example.

Marking a control not applicable removes it from the calculation rather than scoring it zero, so a genuinely irrelevant control does not permanently depress the score and tempt people into fudging it.

The 12-Control Baseline

The baseline is deliberately short. Twelve controls organised by the NIST CSF 2.0 functions, chosen to cover what actually goes wrong, so that a small team can hold the whole programme in view instead of drowning in a several-hundred-line register that never gets updated. Each control carries a priority that drives the remediation ranking, and cross-references to the four frameworks people are usually asked about.

The search box filters on any of it — control title, function, or a framework identifier. Typing CC6, 8.15, or PR.AA jumps to the control that reference belongs to, which is the quick way to answer “what do we have for this?” when a questionnaire cites an identifier. These cross-references are navigational aids for finding your way around a baseline, not an equivalency opinion; for working through NIST CSF 2.0 subcategory by subcategory, the NIST CSF mapper covers the full framework.

How the Remediation Queue Is Ranked

Every control that is not implemented or verified becomes a remediation item, scored so that the order reflects what should be done next rather than what happens to be at the top of the list:

score = (priority × 5) + 5 if the target date has passed + 2 if no owner is named

Priorities run 3 to 5, so the base score is 15, 20, or 25. The two modifiers are what make the ranking useful. An overdue target date adds 5, which lifts a neglected medium-priority item above an on-track one. A missing owner adds 2, because an unowned control is not being worked on by anyone regardless of what its status says — that is the failure mode the score is built to surface.

Each item carries a concrete next step. Controls at not started get the baseline’s implementation guidance; anything already in progress gets the instruction to move to implemented and then independently verify the evidence, which is the step programmes skip.

Evidence References

Every control has a free-text evidence field, and it is there because a status without evidence is an opinion. A ticket number, a policy document reference, a test result, or a date — anything that lets a different person confirm the claim months later without reconstructing it from memory.

Keep it a reference rather than the artifact itself. The workspace is a tracker, not a document store, and pasting a policy body or log extract into it neither helps you nor belongs in browser storage.

Risk Register

Alongside the controls sits a compact risk register: a scenario title, likelihood and impact each scored 1 to 5, an owner, and a treatment. Score is likelihood times impact, and total exposure is the sum across all recorded risks. Any single risk at 20 or higher raises a critical finding.

These are inherent scores — before treatment effectiveness is taken into account — and reading them as residual risk overstates your position. The register is here so control work stays connected to the reasons for it; for a full likelihood-and-impact register with treatment tracking, use the risk matrix calculator.

What Gets Flagged

• Baseline implementation below 50% — high, with the count of applicable controls not yet implemented.
• Control gaps need owners — medium. Usually the most actionable item on the page, and the cheapest to fix.
• Remediation targets are overdue — high, counting open items whose target date has passed.
• Critical inherent risk recorded — critical, when any risk scores 20 or above.
• Program coverage calculated — info, restating the weighted percentage across applicable controls.

Private, Local, and Not an Audit

The workspace is held in this browser’s local storage: 30-day expiry, up to 24 saved workspaces, 128 KiB each, with up to 200 controls and 200 risks. Nothing is transmitted, there is no account, and clearing site data deletes it. Saved workspaces carry notes, tags, and an activity trail, and reloading one written before a baseline control was added fills in the new control rather than failing.

Two limits to be straight about. This is a readiness aid, not an audit, a certification, or a control equivalency opinion — no result here substitutes for an assessor’s judgement. And because storage is per-browser, this is a tool for one person to think with and export from, not a shared system of record for a team.

How to Track a Control Baseline

1. Enter the organisation, industry, and employee count to frame the assessment.
2. Set a status on every control. Be honest about implemented versus verified — the gap between them is the point.
3. Name an owner for every gap. Unowned gaps are counted and ranked higher for a reason.
4. Add target dates so overdue items surface on their own instead of needing a review meeting.
5. Record an evidence reference for anything marked implemented or verified.
6. Record your top risks with likelihood and impact to connect the control work to its justification.
7. Work the remediation queue from the top, then re-run it and watch coverage move.
8. Save the workspace and revisit it monthly.

Frequently Asked Questions

What is the difference between implemented and verified?

Implemented means the team believes the control is built and operating. Verified means someone independently confirmed it against evidence — a restore actually performed, an access review actually sampled, a configuration actually inspected. The weighting is 0.8 against 1.0, so a programme claiming full implementation with little verification scores visibly below one that has proven its controls.

Why does a control with no owner rank higher in the queue?

Because nobody is working on it. Status describes intent; an owner is what makes intent happen. Unowned gaps are counted separately and add to the remediation score for exactly this reason, and assigning owners is usually the fastest improvement available.

Should I mark a control not applicable?

Only when it genuinely does not apply to your environment, and record why in the notes. Not applicable removes the control from the denominator rather than scoring zero, so it raises your coverage — which makes it easy to misuse. A control that is inconvenient is not a control that is inapplicable.

Is 12 controls enough for a security programme?

It is enough to start, and starting is the problem this solves. A 300-line register that nobody maintains provides less assurance than 12 controls with real owners, dates, and evidence. Once these are verified rather than merely implemented, a framework-specific assessment is the right next step.

Can this prepare me for a SOC 2 audit?

It will show you where the obvious gaps and unowned controls are, which is useful preparation. It is not a gap analysis against the Trust Services Criteria and it is not an audit. For that, use the SOC 2 gap analysis, and expect an assessor to have views of their own.

Is my control data uploaded anywhere?

No. Everything runs in your browser and saves to local storage on this device only. That is the right handling for what is effectively an inventory of your organisation’s weaknesses.

Can my team share a workspace?

Not directly — storage is per-browser, so each person’s workspace is their own. Treat it as a tool for assembling and maintaining a view you then export and circulate, rather than a shared system of record.

Do I need an account?

No. This and the rest of our compliance tools are free and need no signup. To turn identified gaps into written policy, see the security policy generator; to extend supplier risk into a portfolio view, see the supply chain risk assessor.