Information Security Program · Topic 2 of 6
Frameworks, Policies and Program Metrics
Using security standards and frameworks, the hierarchy of policies, standards, procedures and guidelines, policy exceptions and meaningful metrics.
- 3 min
- Frameworks are selected and tailored, not adopted blindly.
- Policy states intent; standards and procedures are mandatory detail; guidelines are advice.
- Exceptions need risk assessment, authorized approval and an expiry date.
What it is
Industry standards and frameworks give the program a recognized structure for choosing and organizing controls. Policies, procedures and guidelines state management's rules and how to follow them. Program metrics show whether the program is working and help management make decisions.
How it works
Standards and frameworks
| Framework | Use in the program |
|---|---|
| ISO/IEC 27001 | Management system requirements; certification possible |
| ISO/IEC 27002 | Control guidance |
| NIST Cybersecurity Framework | Outcome functions for profiling current and target states |
| NIST SP 800-53 | Catalogue of security and privacy controls |
| COBIT | Governance and management of enterprise IT |
| CIS Controls | Prioritized technical safeguards |
| PCI DSS | Mandatory requirements for card data |
A framework is chosen to fit the organization's needs, regulatory environment and maturity, then tailored. Some, such as PCI DSS for card data, are contractually required.
The policy hierarchy
| Document | Nature |
|---|---|
| Policy | High-level statement of management intent and direction; approved by senior management; changes rarely |
| Standard | Mandatory, specific requirements that support a policy, such as minimum password length |
| Procedure | Mandatory step-by-step instructions for a task |
| Guideline | Recommended practice; not mandatory |
Good policies are short, clear, aligned with business objectives, owned, communicated, acknowledged by staff and reviewed regularly. Technology-specific detail belongs in standards and procedures, so the policy does not need rewriting each time technology changes.
Exceptions
When a requirement cannot be met, a policy exception process records the reason, the risk, compensating controls, the approver with the right authority and an expiry date. Exceptions are tracked and reviewed; a large number of exceptions to one rule suggests the rule needs revisiting.
Program metrics
Metrics should be meaningful to their audience, accurate, consistent over time, cost-effective to collect and tied to objectives.
| Audience | Useful metrics |
|---|---|
| Board and executives | Trend of top risks against appetite, progress on strategic initiatives, major incidents and their business impact |
| Management | Control effectiveness, time to remediate critical vulnerabilities, policy exception trends |
| Operations | Patch levels, alert volumes, scan coverage |
Metrics should measure outcomes (reduced risk, faster containment) more than activity (number of sessions held). Check that the data behind a metric covers the whole population, for example that patch compliance counts all devices found on the network, not only those reporting to the management tool.
When a question asks for the BEST metric for the board, choose one that shows risk or business impact over time, not a technical count.
How the exam asks about this
- "Which document should be technology-neutral and approved by senior management?" The policy.
- "Many requests for exceptions to the same standard." Review whether the standard still fits the business.
- "Patch compliance is 98 percent of managed devices, but discovery finds more devices." Reconcile the populations before reporting.
What to remember for the exam
- Frameworks are selected and tailored, not adopted blindly.
- Policy states intent; standards and procedures are mandatory detail; guidelines are advice.
- Exceptions need risk assessment, authorized approval and an expiry date.
- Metrics fit the audience and measure outcomes.
- Verify the completeness of metric data.
A dashboard full of green activity metrics can hide a rising risk. If the board cannot tell whether risk is falling, the metrics are not doing their job.
Common mistakes
Putting technical settings in the policy.
Granting permanent exceptions.
Reporting activity counts to the board.
Check yourself
What is the difference between a standard and a guideline?
A standard is mandatory and specific; a guideline is recommended practice.
What should a policy exception record include?
The reason, the risk, compensating controls, an authorized approver and an expiry date.
What makes a metric suitable for the board?
It shows risk or business impact and trends over time in business terms.
Topic 2 of 6 in Information Security Program
Test yourself on Information Security Program
The full ISACA CISM question bank has 1,044 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by ISACA. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.