Most organisations have policies ; but very few have policies people actually follow.
The problem isn’t the content. It’s the complexity, the jargon, and the fact that most policies look like they were written by lawyers who never met the people using them.
A real GRC program starts with clear, practical policies that teams understand, adopt, and actually use in their daily work.
Here are the 10 essential policies every organisation needs ; no fluff, no filler, just what works.
You don’t need 40 policies. You need a lean, coherent policy framework that covers governance, security, data, risk, and operations ; without drowning your teams in paperwork.
Every policy should answer three questions:
- What is required?
- Who owns it?
- How do we prove it?
These 10 policies form the backbone of any serious GRC program. Let’s break them down.
1. Information Security Policy (The Master Policy)
This is your North Star. It defines the organisation’s security objectives, commitments, and expectations.
It should:
- define the ISMS or security governance framework
- assign responsibilities (CISO, owners, managers)
- set high-level security principles
- provide authority for all other policies
- align with ISO 27001, NIS2, DORA
A good Information Security Policy is short, clear, and directive ; not a 25-page novel.
2. Access Control Policy
This is where most breaches happen, and regulators look first.
Must include:
- how accounts are created
- how accounts are removed
- MFA requirements
- privileged access rules
- periodic access reviews
- joiner–mover–leaver (JML) workflow
- authentication standards
Anecdote: In 90% of NIS2 audits, weak access control is the first finding. This policy fixes that.
3. Asset Management Policy
You cannot protect what you cannot identify.
Cover:
- hardware inventory
- software inventory
- cloud assets
- data classification
- ownership rules
- third-party systems
- configuration baselines
This is also where the AI Act begins: identifying AI assets before governing them.
4. Risk Management Policy
The backbone of every GRC program. Without it, your controls have no logic.
Must define:
- risk methodology
- threat sources
- likelihood & impact scales
- approval of risk acceptance
- link to treatment plans
- roles & responsibilities
- review frequency
If you don’t document your methodology, your risk register is not defensible.
5. Incident Response Policy
NIS2 and DORA make this mandatory ; with strict reporting rules.
Include:
- severity levels
- escalation paths
- roles (technical, legal, exec, comms)
- 24h / 72h reporting workflow
- communication rules
- evidence preservation
- CSIRT interaction
- post-incident review
A policy that spells out “how we handle bad days” is non-negotiable.
6. Business Continuity & Disaster Recovery Policy (BC/DR)
Your resilience blueprint.
Cover:
- BIA requirements
- recovery objectives (RTO/RPO)
- backup strategy
- crisis management
- DR testing
- fallback locations
- plan ownership
Regulators want proof you can keep operating ; even when suppliers fail.
7. Supplier & Third-Party Security Policy
NIS2’s most underestimated requirement.
- supplier classification (critical / important / non-critical)
- due diligence steps
- contractual security clauses
- ongoing monitoring
- onboarding/offboarding
- subprocessor transparency
- exit strategy
If your suppliers aren’t governed, you’re not compliant.
8. Data Protection & Privacy Policy
GDPR makes this mandatory, but teams often misinterpret it.
Should include:
- lawful basis of processing
- data subject rights
- retention rules
- data minimisation
- data transfers
- DPIA criteria
- breach notification rules
- privacy by design requirements
Make it practical ; not written in legalese.
9. Acceptable Use Policy (AUP)
Your frontline defence against human error.
Should clearly state:
- acceptable use of IT systems
- restrictions (e.g., personal email, USBs)
- AI usage rules
- password expectations
- remote work requirements
- reporting suspicious behaviour
The AUP should be short enough that employees actually read it.
10. Secure Development & Change Management Policy
The policy that keeps engineering aligned with governance.
- secure coding expectations
- code review requirements
- pipeline security
- dependency management
- change approval workflow
- testing requirements
- segregation of duties
- infrastructure-as-code governance
This is also where AI-generated code must be reviewed for security.
Bonus Policies (Depending on Context)
If relevant to your organisation, consider adding:
- Cryptography Policy
- Logging & Monitoring Policy
- AI Governance Policy (aligned with EU AI Act and ISO 42001)
- Vulnerability Management Policy
- Remote Work Policy
- Mobile Device Policy
- Records Retention Policy
These are not mandatory for everyone ; the top 10 are.
Free Templates
Below are simplified, ready-to-use policy templates you can adapt. They’re intentionally short and practical.
Final Thought
Policies are not documents ; they are expectations made explicit.
If your policies are too long, too theoretical, or written in legal jargon, your GRC program will collapse under its own weight.
Start lean. Write clearly. Assign ownership. Review regularly. And make policies the living backbone of your governance ; not paperwork for the auditor.
If you want policy templates aligned with ISO 27001, NIS2, DORA, GDPR, and the EU AI Act ; that’s exactly what we share in the Cyber Academy Lead Implementer courses. Join the next session and get instant access.