A control is only as useful as the record that shows it worked. This page turns that idea into yes or no tests, for example whether a record carries a date. A security compliance checklist is a list of such tests. They show whether each control has a definition, an owner, a dated record, a recheck and a follow-up. This one has 16 checks in four groups, scored out of 32.
Last reviewed 2026-11-01 by Manish Sharma.
This page is for a compliance lead, IT head or business owner at a firm in India or the GCC. The reader wants to test the controls already in place. A control is a safeguard in your cybersecurity set-up, such as a review of access rights, that meets a requirement. A requirement is a rule that a law, contract, customer or standard sets. Evidence, in contrast, is a record of what a control did, with its date. The checklist is a self-check, not an audit, a certificate or legal advice, and it names no regulation. This article offers no download, template or file. If you want a sheet, copy the tables into your own and add an owner, a date and a score column.
Security Compliance Checklist: The Short Answer
The 16 checks fall into four groups. Each one gives the evidence to keep as well as a yes or no pass test.
Key Takeaway A control counts as shown when a dated record says what it did.
The four groups are:
- Controls (checks 1 to 4)
- Evidence (checks 5 to 8)
- Monitoring (checks 9 to 12)
- Follow-up (checks 13 to 16)
Three NIST documents from the US serve as references, but this page does not treat any of them as a standard to comply with. The groups, the pass tests and the marks are Signisys’ own working method. This page also marks each quotation where it appears.
How to Score the Security Compliance Checklist
Give a check 2 (Pass) when it meets its test and a dated record is on file. A check scores 1 (Partial) when the test holds for only some of the scope or the record is incomplete. It scores 0 (Fail) when it does not meet its test or you have not run it. A control that works but has no dated record does not reach Pass. The maximum is 32, and all of this scoring is Signisys’ own.
The checklist sets no target total. Read the Fails in each of the four groups, because a good total can hide a group where every check failed.
Where a test says sample, choose three items from the full list by drawing lots. Write down which three, so a colleague can repeat the test. Use the same three controls for checks 5 to 8. If a list holds fewer than three items, test all of them.
If a check does not fit your firm, mark it N/A and subtract 2 from the maximum of 32. For example, check 15 does not apply when you hold no exceptions.
Also keep the results in one dated evidence folder. In our view the person who runs a check should not be the control’s owner.
A full score is not a certificate, and it does not show that you meet any framework, a regulator’s rule or a customer’s contract.
Security Compliance Checklist, Checks 1 to 4: Controls
These four checks test whether each control has a written statement, a place in the control list, an owner and a policy. Each check below names the evidence to keep as well as a pass test. The sample rule and every pass test in this security compliance checklist are ours.
Checks 1 and 2: Written and Covered
SP 800-53 Rev. 5 (September 2020) is a US catalog of controls, and this page uses it for family names only. Its page says “The controls are flexible and customizable and implemented as part of an organization-wide process to manage risk.” Family names such as “Access Control” and “Audit and Accountability” give a reference list.
| Check | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| 1. Each control is written as a statement someone else can test. | The register entry, including what is covered and what working looks like. | If a colleague, given only the entry, can say what to look at to see each of three sampled controls working. | Our check. |
| 2. The control list covers each control family you chose. | Your chosen family list, with a control for each family or a written reason when none applies. | If every family on the list holds a control or a dated reason it does not apply. | Family names from SP 800-53 Rev. 5; the rule is our check. |
Checks 3 and 4: Owner and Policy
NIST’s Cybersecurity Framework 2.0 (CSF 2.0, 26 February 2024, US) names people who develop and lead cybersecurity programs as its primary audience. Its GV.RR-02 outcome reads “Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced”, and GV.PO-02 reads “Policy for managing cybersecurity risks is reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organizational mission”. Both name an idea, while neither sets the pass tests below.
| Check | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| 3. Every control has one named owner. | The register column, with a person’s name against each control. | If each of three sampled owners confirms the role, and each name is a person, not a team. | Idea of defined roles from CSF 2.0 GV.RR-02; one named person per control and the sample are our check. |
| 4. Each control sits under an approved policy with a review date. | The policy, its approver and the date it was last reviewed. | If each sampled control points to a policy that names an approver and a review date. | Idea of a reviewed policy from CSF 2.0 GV.PO-02; the approver, the review date per control and the sample are our check. |
Security Compliance Checklist, Checks 5 to 8: Evidence
A policy shows what a firm intends, while a record shows what happened. Four checks follow. This part of the security compliance checklist tests the record behind each control. Every test is our check, and this page takes no evidence rule from the NIST documents named here.
| Check | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| 5. Each evidence record names its control and the requirement it answers. | An evidence index row, including a control ID and the requirement’s source reference. | If each of three sampled files carries a control ID and a requirement reference. | Our check. |
| 6. Each record shows its date, who produced it and the system it came from. | The file, or its index row, including all three. | If a colleague reads all three from each sampled file without asking its author. | Our check. |
| 7. Evidence is a result of the control running, not only a policy text. | A test result, a log extract or a signed review for each sampled control. | If each sampled control has a dated result of it running, and not a policy text alone. | Our check. |
| 8. Evidence is indexed and held in one place, with a named access list. | The index, the store it points to and the access list. | If a colleague who is not the owner, using the index alone, finds each of three sampled records in the store the index names, and the access list names people. | Our check. |
A record that exists is not the same as a record that shows the control worked.
Checks 9 to 12: Is There a Routine That Rechecks the Controls?
These four checks of the security compliance checklist test that a routine exists and leaves a trail, not how to build one. For the routine itself, read seven steps for a routine of yes/no checks. NIST SP 800-137 (September 2011) is US guidance for federal information systems, and it covers security monitoring, which, in our view, is narrower than compliance. It defines continuous monitoring as “maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions”. Check 10’s interval is your firm’s own choice, and this article sets none.
| Check | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| 9. A written routine for rechecking controls exists. | The routine document, including the list of controls it covers. | If it says what is rechecked and covers every register control or names those it leaves out. | SP 800-137 for the idea; the pass test is our check. |
| 10. The routine has one owner and a stated interval for each control. | The owner’s name, and the interval the routine states against each control. | If one person owns the routine and every register control has an interval your firm chose. | Our check. |
| 11. The latest rerun of each control left a dated result. | The result log, including the latest dated row for each control. | If each of three sampled controls has a latest result dated within the interval the routine states. | Our check. |
| 12. Someone other than the control owner reads the results. | A dated sign-off or note against the latest results. | If the latest result for each of three sampled controls has a dated read note from a person who is not its owner. | Our check. |
Key Takeaway A recheck counts when it leaves a result with a date on it.
Security Compliance Checklist, Checks 13 to 16: Follow-Up
The last four checks test what happens after a control fails a test. For check 16, CSF 2.0 ID.IM-01 states “Improvements are identified from evaluations”. The framework describes outcomes. In its own words, “The CSF does not prescribe how outcomes should be achieved.” This checklist does not treat it as a standard to comply with, while the comparison between runs is our check.
| Check | Evidence to keep | Pass test | Basis |
|---|---|---|---|
| 13. Every finding has an owner, a due date and a status. | The findings log, including all three fields. | If each of three sampled findings shows an owner, a due date and a status. | Our check. |
| 14. Closed findings carry a dated re-test. | The re-test result, filed against the finding. | If each of three sampled closed findings has a re-test result dated after the fix. | Our check. |
| 15. Each exception to a control is approved and has an end date. | The exception record, including its approver, reason and end date. | If each sampled exception names an approver and a reason, and its end date has not passed. | Our check. |
| 16. The last run of this checklist is on file and its fix list is tracked. | The filed score sheet, including the Fails counted in each group. | If the previous sheet is on file and its fixes appear in the findings log. | CSF 2.0 ID.IM-01; the comparison is our check. |
Fixing the Gaps: What to Do After Scoring Your Security Compliance Checklist
Before fixing anything, note the Fails under each of the four headings. Our fix order is a view, not a standard: fix the Controls group first. Check 5 asks each record to name a control ID, and a control with no register entry has none to name. Evidence follows, then Monitoring, then Follow-up, and a Partial sits after the Fails in its group.
When a check fails, write an owner, the fix and a re-test date in the findings log from check 13. That log also lets the next run of the checklist compare results, which is what check 16 tests. When two Fails compete, judging how serious a finding is helps to decide which goes first.
Write the re-test date beside each fix in the findings log, so the next run has a starting point.
Set a date for the next run of the security compliance checklist and file the new sheet with the evidence when the run ends. If the sheet itself is the weak point, try five tests to run on your own tracking sheet. For the wider topic, see improving compliance visibility.
When a Second View Helps, and the Limits of This Checklist
In our view, ask for a second view when Fails sit in more than one group or when no one can name the owner of a control. Ask also when a customer or regulator has asked for evidence in a form you do not have.
The checklist tests your own controls and records only. It does not explain why gaps stay hidden, build the checking routine or compare tools, and it names no tool. For why gaps stay hidden, read how a control can look finished on paper. Instead of searching for the rules that apply to you, it starts from controls you already have. It also names no regulation and says nothing about the law in India or the GCC. It is not an audit, a certificate or legal advice. A full score does not show that you meet a framework, a regulator’s rule or a customer’s contract. The three NIST documents are US publications, used here as references.
Signisys helps organizations find, prioritize and reduce security risks, with clear visibility of security posture and compliance. Its solution page also lists a review of security controls and exposures against agreed standards. It lists reporting and remediation tracking as well, which shows risk, progress and evidence for audits. Signisys agrees the exact scope for each engagement. Our Solution: VAPT and Cybersecurity Risk Assessment. Our Service: Cybersecurity Services.
Security Compliance Checklist FAQ
What should a security compliance checklist include?
How do I score where we stand?
If every check scores 2, are we compliant?
Which check should we fix first?
Is there a PDF, template or Excel version of this checklist?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.