A security strategy and governance checklist tests whether leadership has set direction, assigned accountability and can evidence that controls work. The nine steps below follow how an IS auditor at JCSS Indonesia reviews governance: framework, roles, risk, response, policy, awareness, assurance, compliance and continual improvement.
Why does security governance come before security tools?
Because tools only work when someone decides what to protect, who is accountable and how much risk is acceptable. Governance supplies those decisions.
The NIST Cybersecurity Framework 2.0 made this explicit by adding Govern as a sixth function; NIST's FAQ explains that governance activities were previously embedded within Identify and were elevated to stress their importance. Its Govern categories cover organisational context, risk management strategy, roles and responsibilities, policy, and supply chain risk. In audits, weak governance shows up as controls that exist on paper, with no owner and no evidence of operation.
What are the nine steps of the checklist?
Nine steps cover the governance lifecycle from framework to improvement. Each has a question to ask and evidence to retain.
| Step | Question to ask | Evidence an auditor expects |
|---|---|---|
| 1. Governance framework | Which framework or standard do we follow, and who approved it? | Approved framework, scope statement, board or executive minutes |
| 2. Roles and responsibilities | Who owns security decisions and each control? | Role descriptions, RACI, named control owners |
| 3. Risk assessment | What are our key risks and how are they rated and treated? | Risk register, methodology, treatment plan |
| 4. Incident response | What happens in the first hours of an incident? | Tested plan, contact list, exercise records |
| 5. Policies and procedures | Are rules written, approved and current? | Policy set with owners and review dates |
| 6. Awareness training | Do staff know their obligations? | Attendance and completion records |
| 7. Security audits | Who independently tests our controls? | Audit plan, reports, tracked findings |
| 8. Compliance | Which laws and contracts apply and are we meeting them? | Obligations register, compliance reviews |
| 9. Continual improvement | How do lessons change the programme? | Management review minutes, closed actions |
How should you set up the framework, roles and risk assessment (steps 1 to 3)?
Choose one recognised framework, approve it at executive level, assign named owners, and base priorities on a documented risk assessment.
Framework. Many organisations use ISO/IEC 27001 for a certifiable management system, with the NIST framework as a reference model for outcomes. Whatever you pick, define scope: legal entities, systems, locations and third parties.
Roles. Security cannot sit only with IT. Define who owns risk acceptance (usually senior management), who runs controls day to day, and who provides independent assurance. Avoid giving the same person authority to operate and to review a control.
Risk. Document the method: how assets are identified, how likelihood and impact are rated, and who approves residual risk. A risk register that nobody has reviewed in a year is an audit finding in itself. Our GRC automation guide covers tooling for the register.
What do incident response, policies and training need (steps 4 to 6)?
They need to be written, approved, rehearsed and evidenced. An untested plan is a hypothesis, not a control.
- Incident response: define severity levels, decision rights, escalation and communication, including legal and regulatory notification. Indonesian entities processing personal data should check obligations under Law No. 27 of 2022 on Personal Data Protection with legal counsel. Run a tabletop exercise and keep the record.
- Policies: keep a short set of approved policies, such as information security, access control, acceptable use, supplier security and incident management, each with an owner and a review date. Procedures translate them into steps staff can follow.
- Training: train all staff, with additional modules for administrators and developers, and keep completion evidence. Phishing simulations are useful, provided results lead to coaching rather than blame.
How do audits and compliance work together (steps 7 to 9)?
Independent audits test whether controls operate; compliance tracking shows which obligations apply; improvement closes the loop through management review.
An effective assurance plan combines internal audit, technical testing such as VAPT, and where relevant external certification. Findings should be tracked to closure with owners and dates. Maintain an obligations register covering law, regulators, customer contracts and standards, and review it when the business changes. Finally, hold a periodic management review that looks at incidents, audit results, risk changes and resource needs, and records decisions. Under ISO/IEC 27001, internal audit, management review and corrective action are core management-system elements, as described in ISO's own committee material.
What are common governance gaps auditors see?
Typical gaps are policies without owners, risk registers without reviews, untested response plans, unmanaged supplier access and findings that never close.
Watch for these patterns:
- security reporting to a manager with no access to the board;
- controls assigned to "IT" rather than a named person;
- exceptions granted informally, with no expiry;
- incident plans that exclude legal, communications or business leaders;
- audit findings reopened year after year.
How can JCSS Indonesia help?
We review governance against your chosen framework and report gaps as a draft for partner review, with evidence requests you can action. See our internal audit, ITGC and cybersecurity service. For API-specific controls, our API security checklist is a good companion.
Frequently asked questions
What is a security governance framework?
It is the set of structures, roles, policies and decision rights through which an organisation directs and controls information security. It defines who is accountable, what standards apply, how risk is assessed and accepted, and how performance is reported to senior management. ISO/IEC 27001 and the NIST Cybersecurity Framework are common reference points.
Who should own security governance in a company?
Ultimate accountability sits with the board and executive management, who set risk appetite and approve policy. Day-to-day leadership is usually a CISO or equivalent security lead, with control owners across IT, HR, procurement and operations. Independent assurance comes from internal audit or an external reviewer, separate from those who operate the controls.
How often should the checklist be reviewed?
Review it at least annually and whenever there is a material change: a merger, new system, major supplier, incident or regulatory development. Policies should carry review dates, risk registers should be updated as conditions change, and management should consider results at a scheduled review, with minutes retained as evidence.
Does the checklist replace ISO 27001 certification?
No. It is a diagnostic aid. ISO/IEC 27001 is a formal standard against which an external certification body audits your management system. The checklist helps you see where you stand and what evidence is missing, but it does not result in a certificate or an audit opinion.
What evidence do auditors ask for first?
Usually the scope statement, approved policies, risk register and methodology, organisation chart with security roles, the last incident-response test and recent audit reports with closure status. Having these ready, with dates, owners and approvals visible, shortens fieldwork and reduces follow-up requests.
General information only, not legal or tax advice for your specific facts. Regulations change; confirm the current position with JCSS Indonesia before acting.