Developing information security policies: What's in it?

What is information security policy?

Information security policy is the coherent framework for an organisation to guide the protection of information. It lays down principles, standards, responsibilities and decision-making and forms the basis for procedures and working instructions.

The policy supports demonstration: management, employees and suppliers can see what agreements apply, who makes a choice and how the organisation checks whether measures work.

Policy sets out choices arising from risks and organisational goals. The value becomes visible in ownership, execution, control and proof.

Is information security policy mandatory?

There is no general yes-or-no answer for any organisation. The need can be followed by legislation, contracts, sectoral requirements, governance, customer expectations, certification or own risk management.

ISO 27001 sets requirements for information security policy within an ISMS. The Dutch Cybersecurity Act requires organisations within the scope to have appropriate control of cyber risks and clear responsibilities. Policy helps to capture choices; implementation and demonstration remain at least as important.

Start with risks, not with a template

Research what information is important, what processes should be short and which systems and suppliers are needed for this. Also look at threats, special access rights, legal requirements and the risk appetite of the board and executive management.

One Information security risk analysis helps to underpin choices. A template will then remain useful as a structure and checklist.

• What services are critical for customers, clients or employees?
• What information requires additional protection against inspection, modification or loss?
• Which systems and links support the critical processes?
• Which suppliers have access or recovery responsibility?
• What risks does the organisation accept and who decides?

What should be minimal in information security policy?

The following topics form a useful basis. The table is not a universally mandatory table of contents; add or split topics when risk and complexity so require.

Scope: What is the policy for?

Name employees, management, volunteers, temporary staff and suppliers insofar as they have access to information or systems. Also describe locations, cloud environments, devices, data and processes within the scope.

A clear scope prevents parts between departments or contracts from disappearing. Please explicitly record exceptions and designate an owner.

Roles and responsibilities

It's too wide to be responsible for security. the board and executive management determine direction and risk readiness. Process owners and information owners make choices about their processes and data. IT manages measures, while security, privacy, HR and internal control provide its own expertise and review.

Suppliers perform agreed tasks. The organisation itself keeps an eye on scope, performance, risks and evidence. Employees follow the usage rules and report deviations.

Risk management

Describe how risks are identified, assessed, treated, accepted and reviewed. Specify who owns, which decision limits apply and which changes require a new assessment.

Link policy choices to realistic scenarios and critical processes. This prevents a library from taking measures without a clear relationship with business continuity or data protection.

Access management and authorisations

Set basics for least privilege, multifactor authentication, management accounts, function separation and periodic access reviews. Also describe onboarding, job change, resignation and exceptions.

Make clear who applies for access, who approves, who performs technical tasks and who checks periodically.

Patch and vulnerability management

Patch management requires agreements on scope, priority, deadlines, critical vulnerabilities, exceptions, vendor systems, reporting and verification. The policy provides the framework; technical standards and working instructions shall include the implementation.

Identify who accepts risk when an update cannot be temporarily implemented and how compensatory measures are followed.

Backup and Recovery

Determine which data and systems are backed up, with which frequency and retention period and how backups are protected against modification or deletion. Link recovery to RTO and RPO where these concepts are useful.

Backup is only complete when ownership, restoration tests and reporting on the outcome are arranged.

Incidents and notifications

Define what the organisation treats as a security incident, who reports, through which channel and when escalation is needed. Connect registration, research, restoration, communication, legal notifications and evaluation to the Incident Response Plan.

Make the reporting route also possible outside office hours and practice the agreements with relevant employees and suppliers.

Suppliers and outsourcing

Capture security requirements, access, incident reports, assurance, subcontractors, monitoring, termination and transfer. Contract, SLA, processing arrangements and daily service should be linked.

Suppliers management and independent supplier selection help to make agreements keyable and to arrange the exit already at the beginning.

Logging and monitoring

Determine the purpose of collecting logs, which systems are relevant, who has access and how long data are stored. Record who assesses reports and when a deviation is escalated.

Take privacy weighings with you and periodically check whether the chosen logging is still useful for detection and investigation.

Employees and secure digital work

Translate formal policy into understandable accounts agreements, MFA, phishing, confidential information, email, file sharing, home working, mobile devices, incident notifications, AI and clean desk or clear screen.

One Handbook Digital Safe Working and an appropriate awareness programme make policy recognisable in daily practice.

AI is now also part of the policy structure

AI affects data classification, personal data, confidentiality, suppliers, human control, employees and decision-making. Determine which applications are allowed and how new AI functions are assessed.

Read what agreements are included in an AI policy.

Does everything have to be in one information security policy?

A clear policy architecture often works better than one very comprehensive document. The main policy includes direction and governance. Theme policy covers, for example, access, backup, suppliers and AI. Procedures describe incidents, onboarding or patching. Work instructions explain daily actions.

A staff manual translates the relevant agreements into safe digital working. Keep references and version management central so that documents do not contradict each other.

How many policy documents do you need?

An organisation does not need to create a huge document library. The appropriate number follows from complexity, risks, size, sector, legislation, suppliers, internal roles and any certification.

Split a topic out when a private owner, target group, decision route or frequent change makes that practical. Combine topics when separate documents add mainly management burden.

Strategic, tactical and operational policies

Strategic policy sets principles, objectives and governance. Tactical documents contain standards, responsibilities and processes. Operational procedures and working instructions describe the day-to-day implementation.

These levels should be linked. A board-level starting point will thus be translated and the execution will provide proof back to the board and management.

Information security policy and ISO 27001

ISO 27001 connects context, leadership, risks, policies, objectives, measures, monitoring, audits and improvement within an ISMS. Information security policy is therefore one part of a working management system.

The document should be consistent with scope, risk assessment and chosen measures. Read more about ISO 27001 guidance and what an ISMS means in practice.

Information security policy and NIS2

The Dutch Cybersecurity Act has been in force since August 15, 2026. Organisations within the legal scope face duty of care, reporting obligations, registration and board-level responsibilities. Policy helps define measures and responsibilities.

The actual control and demonstrability determine whether the agreements work. View NIS2 advice and implementation for translation into its own scope and organisation.

Make policy rules practicable in practice

Security updates shall be carried out in a timely manner as soon as classification, deadlines, responsibility, exceptions, control and reporting are established.

Getting suitable access for employees requires an application, approval, least privilege, periodic review and a service process. Backups are made on a daily basis.Packups also require scope, recovery purpose, protection, tests and an owner.

How do you set up information security policy?

Use a fixed order and have the owners read the content in the interim.

• determine organizational context and scope
• List existing documents and obligations
• analyse risks and collect relevant requirements
• determine the policy architecture and define roles
• write policy and let stakeholders review
• let policies be defined at appropriate management or management level
• plan implementation, communication, controls and update

Who's going to approve the policy?

This depends on governance and internal powers. Overarching information security policies are usually set at a level that can determine direction, means and risk appetite. Theme policy may have another owner and approval route.

Record approval, entry date, owner, version and next review.

How do you implement information security policy?

Translate policy rules to technical configurations, processes, contracts, HR agreements, forms, awareness, controls and reporting. Give each change a owner, planning and demonstrable result.

Publication on intranet does not automatically change the execution. Employees, administrators and suppliers each need a targeted translation.

How do you secure information security policy?

Point out a policy owner, plan reviews and connect the policy with management reporting, monitoring, internal audits, incidents, changes, exceptions and version management. KPIs or KRIs can help when they answer a real steering question.

Evidence shows whether agreements have been made. Developing and securing information security policies links the policy framework to implementation and update. Internal control information security organises the periodic monitoring, checks and evidence.

How often should policies be reviewed?

Choose a fixed review rhythm that fits the organisation and update earlier after incidents, a new supplier, reorganisation, acquisition, new technology, AI, legislation, audit findings or important new risks.

The review does not need to lead to a completely new document. Please also note that the assessment was carried out and why modification was or was not necessary.

Is an example or template sufficient?

An example or template provides structure, topics and inspiration. A useful policy then requires choices about its own processes, systems, risks, suppliers, responsibilities and risk readiness.

Check every standard text for feasibility. An organisation should be able to explain who is carrying out the appointment, how it is done and what evidence is available.

Where does policy often go wrong in practice?

Use these points as a check during writing, implementing and updating.

• the owner or scope remains unclear
• agreements are too common to be executed or checked
• suppliers do not know the relevant agreements
• technical systems do not support the policy rule
• documents contradict each other or have different versions
• exceptions are regulated informally
• lack of evidence and periodic monitoring
• incidents and changes do not result in actualization

Information security policy checklist

Use this compact checklist to assess the policy base and assurance.