1.6 Security Policies & Standards
Security Policies & Standards at a glance
Security governance establishes what an organisation wants to achieve. Policies, standards, procedures and guidelines translate that direction into practical security expectations.
The most important distinction is understanding the purpose of each type of document.
Policy
Establishes high-level management direction and requirements.
WHAT and WHY?Standard
Defines specific mandatory requirements that support policy.
WHAT exactly?Procedure
Provides detailed instructions for performing an activity.
HOW?The document hierarchy
Organisations use different types of security documentation because a single document cannot effectively provide strategic direction, mandatory technical requirements and detailed operational instructions at the same time.
| Document | Purpose | Mandatory? | Think... |
|---|---|---|---|
| Policy | High-level organisational direction and requirements | Yes | What / Why |
| Standard | Specific mandatory requirements | Yes | Exactly what |
| Procedure | Step-by-step instructions | Normally yes when applicable | How |
| Guideline | Recommended good practice | Normally no | Recommended |
| Baseline | Minimum required security or configuration level | Usually yes | Minimum |
Policy tells you what the organisation expects.
Standard tells you the mandatory requirement.
Procedure tells you how to do it.
Guideline tells you what is recommended.
Baseline tells you the minimum acceptable level.
1 Security Policies High-level management direction
What is a security policy?
A security policy establishes management's expectations and direction regarding information security.
Policies should generally describe what must be achieved and why it is required, without becoming unnecessarily dependent on a particular technology.
"Access to organisational information must be granted according to business need and the principle of least privilege."
The policy establishes the requirement without describing exactly how every system must implement it.Policies should have authority
A security policy should be supported and approved by appropriate organisational leadership.
Without management support, a policy may become little more than a document that employees can ignore.
Policy is one of the mechanisms through which senior management turns security governance into organisational requirements.
A good policy should be:
📚 Types of security policy Policies can exist at different levels
Enterprise / Organisational Security Policy
A high-level security policy may establish the organisation's overall approach to information security.
It might cover:
- management commitment to security;
- high-level security objectives;
- roles and responsibilities;
- policy authority;
- compliance expectations;
- risk-management principles;
- enforcement expectations.
Issue-Specific Policy
Issue-specific policies deal with particular security topics.
An Acceptable Use Policy explains how employees are permitted to use organisational computers, networks and internet services.
System-Specific Policy
Some requirements may apply to a particular system, platform or technology environment.
These can define rules governing how the system must be operated or protected.
Policies can exist at different levels, but they should ultimately support the organisation's wider security strategy and governance.
2 Security Standards Specific mandatory requirements
What is a standard?
Standards translate high-level policies into more specific mandatory requirements.
They reduce ambiguity and help ensure consistent implementation across the organisation.
"All sensitive information must be appropriately protected when transmitted across untrusted networks."
"Applications transmitting Restricted information over external networks must use organisation-approved TLS configurations."
The policy establishes the security objective.
The standard makes the requirement more specific.
Examples of standards
Defines mandatory authentication configuration requirements.
Defines approved cryptographic technologies and key requirements.
Defines what systems must log and minimum retention expectations.
Establishes required security configurations for systems.
Defines required remediation or treatment expectations.
Defines mandatory network-security requirements.
Standards are generally mandatory.
If something is merely recommended, it is more likely to belong in a guideline.
3 Security Procedures How to perform the activity
What is a procedure?
A procedure provides detailed instructions describing how a particular task or process should be completed.
Procedures are typically much more operational and detailed than policies or standards.
Procedure for disabling access when an employee leaves:
- Confirm the employee's termination with HR.
- Identify associated user and privileged accounts.
- Disable directory access.
- Revoke active authentication sessions.
- Remove VPN access.
- Disable privileged accounts.
- Recover organisational devices.
- Record completion in the access-management system.
Procedures may change more frequently
Because procedures often contain technical details, they may require updating more frequently than high-level policies.
Policy remains stable
"Access must be removed promptly when employment ends."
Procedure changes
The organisation replaces its identity-management platform.
The high-level policy requirement remains valid, but the detailed account-disablement procedure needs updating.
Policies should normally survive technology changes better than detailed procedures.
4 Security Guidelines Recommended rather than mandatory
What is a guideline?
Guidelines provide recommended approaches and good practices where flexibility is useful.
Unlike standards, guidelines are generally advisory rather than mandatory.
"Where practical, employees working in public places should position laptop screens to reduce the risk of shoulder surfing."
Why use guidelines?
Not every situation can or should be governed by a strict mandatory rule.
Guidelines can:
- promote good security behaviour;
- provide recommendations;
- allow professional judgement;
- offer preferred approaches;
- support users without creating unnecessary rigid requirements.
If the requirement is described as optional, recommended or best practice, think guideline.
5 Security Baselines The minimum acceptable level
What is a baseline?
A baseline establishes a minimum security or configuration level that systems or environments are expected to meet.
The organisation creates a Windows Server security baseline requiring:
- host firewall enabled;
- approved audit logging enabled;
- unused services disabled;
- approved endpoint protection installed;
- disk encryption where required;
- secure administrator configuration.
Every applicable server should meet at least the baseline.
A baseline represents the minimum acceptable security level.
Higher-risk systems may require additional controls.
Baselines support consistency
Without baselines, different administrators may configure similar systems in completely different ways.
Baselines help create repeatable and measurable security expectations.
From policy to implementation
The documentation hierarchy becomes easier to understand when one requirement is followed from top to bottom.
🔐 Worked example: authentication See all document types working together
Organisational systems must authenticate users appropriately before granting access to protected resources.
Privileged administrative access must use multi-factor authentication.
All privileged accounts must use the organisation's approved MFA service and must not use shared credentials.
Step-by-step instructions explain how administrators enrol a privileged account into the MFA platform.
Administrators are encouraged to use phishing-resistant authentication methods whenever supported.
The policy remains broad.
Each lower-level document adds more practical detail.
🔄 Policy lifecycle Policies must be managed, not merely written
Creating a policy document is only one part of policy management.
A useful lifecycle is:
Determine what risk, business objective, regulatory requirement or security need the policy should address.
Draft the policy with appropriate stakeholder input.
Obtain input from relevant security, business, legal, risk, privacy, compliance and operational stakeholders.
Obtain approval from the appropriate organisational authority.
Ensure affected people know that the requirement exists and understand their responsibilities.
Deploy supporting standards, procedures, controls and processes.
Determine whether requirements are actually being followed.
Reassess the policy as technology, business requirements, threats and legal obligations change.
Documentation must be communicated, implemented and supported by real organisational processes.
👥 Policy ownership and responsibilities Someone must own the requirement
Security documentation should have clear ownership.
Provides authority and support for organisational security requirements.
Maintains the document and ensures that it remains appropriate.
Provides subject-matter expertise and helps translate risk into security requirements.
Helps identify relevant legal, regulatory and contractual requirements.
Ensure requirements remain practical and aligned with business needs.
Understand and comply with applicable organisational requirements.
Security policy should not be created by the security team in isolation.
Effective policy requires appropriate business ownership and management authority.
📣 Communication and awareness People need to know the rules
Publishing a 100-page policy document on an intranet does not guarantee that employees understand it.
Organisations may communicate policies through:
An organisation introduces a new policy prohibiting confidential information from being uploaded to unapproved AI services.
Simply publishing the policy may not be sufficient.
Employees need to understand the requirement, why it exists and which approved alternatives they should use.🚦 Policy enforcement Requirements need consequences and controls
Security requirements should be capable of being enforced where appropriate.
Enforcement can include both technical and administrative mechanisms.
System configuration automatically prevents prohibited activity.
Security systems detect potential policy violations.
Managers ensure requirements are followed within their teams.
Deliberate violations may result in consequences according to organisational processes.
Policy says confidential information must not be sent to personal email accounts.
DLP technology may detect and block attempts to send such information.
The technical control helps enforce the policy.⚠️ Policy and standard exceptions When the requirement cannot reasonably be met
Real organisations occasionally encounter situations where a security requirement cannot be implemented exactly as written.
The answer should not simply be to ignore the requirement.
A good exception process may include:
Why can the normal requirement not be met?
What additional risk does the exception create?
Can other controls reduce the risk?
Has the appropriately authorised risk or business owner accepted the exception?
When should the exception be reviewed or end?
Is there a clear record of the decision?
A legacy medical system cannot support the organisation's normal multifactor-authentication standard.
The organisation documents the limitation, assesses the risk, implements additional network restrictions and monitoring, obtains appropriate approval and establishes a replacement date.
That is very different from simply ignoring the security standard.An authorised, documented and risk-assessed exception is different from someone simply choosing not to follow the rules.
🛡️ Compensating controls Alternative protection when the normal control is unavailable
A compensating control is an alternative control used to reduce risk when the preferred or required control cannot be implemented as intended.
A legacy application cannot support modern authentication controls.
Additional protections might include:
Compensating controls do not automatically make every exception acceptable.
The remaining risk still needs to be assessed and appropriately approved.
✍️ Writing effective security requirements Clear requirements are easier to follow and enforce
Avoid vague language
"Users should use good passwords."
The high-level policy requires strong authentication.
A supporting standard then defines the organisation's specific mandatory authentication requirements.
Requirements should be understandable
Good documentation should clearly communicate:
- what the requirement is;
- who it applies to;
- who owns it;
- why it exists where appropriate;
- how exceptions are handled;
- how compliance is assessed;
- when it should be reviewed.
🔀 Conflicting requirements Law, regulation, contracts and policy must align
Internal policies do not exist above the law.
Security documentation may need to reflect:
An internal policy states that all logs are deleted after 90 days.
A new regulatory obligation requires certain relevant records to be retained for longer.
The organisation should update its internal requirements rather than continuing to follow an outdated policy.🔍 Policy review and maintenance Security documentation should evolve
Policies and standards should be reviewed periodically and when significant changes occur.
Review may be triggered by:
New platforms or architectures make existing requirements outdated.
The threat environment changes significantly.
Lessons learned identify weaknesses in existing requirements.
New legislation or regulation creates different obligations.
Acquisitions, new products or operating models alter requirements.
Assessments identify gaps or ambiguity.
Organisations should be able to determine which version of a policy or standard was approved and applicable at a particular time.
📊 Measuring policy effectiveness A policy should change behaviour, not just exist
The number of published security policies is not a particularly useful measure of security effectiveness.
Better questions include:
"We have 72 security policies."
"98% of systems subject to the secure configuration standard currently meet the required baseline."
⚠️ Common mistakes Easy document types to confuse
That level of technical detail normally belongs in standards, baselines or procedures. Policy should generally remain higher-level.
Standards normally establish mandatory requirements. Optional recommendations are more characteristic of guidelines.
Policy establishes the requirement. Procedure describes how an activity is performed.
Guidelines are generally recommendations intended to allow some flexibility.
A baseline normally represents the minimum acceptable level, not the maximum possible protection.
Policies also need communication, supporting controls, monitoring and enforcement.
Organisations should use a formal exception and risk-management process where necessary.
Policies should remain relatively stable but still require review as risks, laws and business requirements change.
Look for what the document is trying to do
Exam questions may describe a document without naming it.
Ask whether the document establishes direction, defines a mandatory requirement, describes steps, offers advice or establishes a minimum.
📜 Policy clues
📏 Standard clues
⚙️ Procedure clues
💡 Guideline clues
📐 Baseline clues
⚠️ Exception clues
📝 Practice scenarios Identify the correct document type
Scenario 1
Senior management states that access to confidential information must be based on business need and least privilege.
Document type:
Policy.
Scenario 2
The organisation states that all privileged accounts must use multifactor authentication.
Document type:
Standard.
Scenario 3
A document lists twelve steps an administrator must follow to create a privileged account.
Document type:
Procedure.
Scenario 4
Employees are advised that, where practical, they should avoid displaying sensitive information while travelling on public transport.
Document type:
Guideline.
Scenario 5
Every Linux server must meet a defined minimum hardened configuration before being placed into production.
Document type:
Security baseline.
Scenario 6
A legacy application cannot meet the organisation's encryption standard.
Best response:
Use the formal exception process, assess the risk, consider compensating controls and obtain appropriate approval.
Scenario 7
A policy still requires employees to use a security technology that the organisation stopped supporting three years ago.
What failed?
Policy review and maintenance.
Scenario 8
The organisation has a comprehensive security policy, but employees have never been told that it exists.
What is missing?
Effective communication and implementation.
Scenario 9
A system administrator dislikes the organisation's security standard and decides not to follow it.
Is this an exception?
No. A valid exception requires appropriate justification, risk consideration and approval.
Quick memory aid
Direct. Specify. Do. Recommend. Minimum.
Which document do I need?
Key takeaways
CISSP objective 1.6 requires security professionals to understand how to develop, document and implement policies, standards, procedures and guidelines.
Policies provide high-level management direction and generally explain what must be achieved and why.
Standards translate policy into specific mandatory requirements.
Procedures provide detailed instructions explaining how activities should be performed.
Guidelines provide recommended practices and normally allow greater flexibility.
Baselines establish minimum acceptable security or configuration requirements.
Security documentation should be approved by appropriate authority, clearly owned, communicated to affected users and supported by practical controls.
Policies and standards must also be reviewed as technology, threats, business requirements and legal obligations change.
When requirements cannot reasonably be met, organisations should use a formal exception process rather than silently ignoring the requirement.
Exceptions should consider business justification, risk, compensating controls, approval and review or expiry.
Most importantly: a policy is only useful when it influences real behaviour and security decisions.
📚 Sources & Further Reading Authoritative references
- ISC2 — CISSP Certification Exam Outline
View official CISSP exam outline - NIST — Security Policy Glossary
View NIST definition and references - NIST SP 800-12 Rev. 1 — An Introduction to Information Security
View NIST publication - NIST Cybersecurity & Privacy Glossary
View NIST glossary