Information security policy: what it is and what it must cover

The information security policy is the document in which an organisation sets out how it protects the data it handles: who can access what, how it is stored, how it is encrypted and what is done when something fails. It is not a bureaucratic formality or an annex that is signed and filed away: it is the practical translation of a legal obligation under the GDPR. This guide explains what it is, how it connects with data protection law, what it must cover and how it is really structured in a business.

What is an information security policy?

An information security policy is the internal document where an organisation defines how it protects the data and the systems it uses to process them. It establishes the access rules, the technical measures applied, staff responsibilities and the procedures in the event of incidents. Put simply: it is the manual for how the company safeguards the information entrusted to it by its customers, employees and suppliers.

It is worth distinguishing it from other documents with which it is sometimes confused. The privacy policy is a public text, addressed to data subjects, which informs them of what data are processed and for what purposes (the duty to inform under art. 13 GDPR). The information security policy is the opposite: it is internal, it is not published, and it describes the specific measures that make it possible for those data to be protected. One looks outward; the other, inward.

Its real function is not to have a PDF to show if someone asks for it. It is to set down in writing, coherently, how the organisation behaves with information: what is allowed, what is not, who is responsible for each piece and what is done when something breaks. Without that framework, each employee improvises and security depends on habit rather than on a common rule.

Its relationship with the GDPR

The information security policy does not stem from an organisational whim: it is the usual way of complying with several specific GDPR obligations. The Regulation does not impose a document with that exact name, but it does require the result that document pursues.

The cornerstone is art. 32 GDPR, on security of processing. It requires the controller and the processor to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. The key words are appropriate to the risk: there is no closed, one-size-fits-all list. What is enough for a practice with two employees is not enough for a platform that processes data on thousands of people. Art. 32 itself mentions, among the possible measures, encryption and pseudonymisation, the ability to ensure the confidentiality, integrity, availability and resilience of systems, the ability to restore access to data after an incident, and a process for testing and evaluating the effectiveness of those measures.

That technical obligation rests on a more general principle. Art. 5(1)(f) GDPR establishes the principle of integrity and confidentiality: data must be processed in a way that ensures appropriate security, including protection against unauthorised or unlawful processing and against accidental loss or destruction. The security policy is, precisely, the way to bring that principle down to concrete measures.

And there is a third axis that is often forgotten: the accountability of art. 5(2) GDPR, reinforced by art. 24, which requires the controller not only to implement measures, but to be able to demonstrate that it implements them. A written security policy, reviewed and consistent with the real activity, is one of the main pieces of evidence of that diligence. Being protected is not enough: you have to be able to prove it.

What the policy must cover

There is no universal template, because the content depends on each organisation's risk. But there is a set of blocks that a well-built information security policy should address in almost any company. These are the main ones.

Role-based access control

Each person should access only the data they need for their function, and no more. This translates into access profiles defined by role, granting and revoking permissions when someone joins or leaves the company, and logging of who accesses what. The principle of least privilege is the backbone of the whole policy: most internal incidents stem from excessive access that no one reviewed.

Passwords and authentication

Individual passwords (never shared between people), strong and renewed at any suspicion of compromise. Wherever possible, a second authentication factor on critical access. A clear policy here avoids the most common scenario: the office's single password stuck on a sticky note under the keyboard.

Encryption

Encryption of devices that leave the office (laptops, external drives, corporate phones) and of sensitive communications and files. Encryption is the measure that turns the loss of a laptop into a scare rather than a data breach: if the drive is encrypted, whoever finds it accesses nothing.

Backups

Periodic, verified backups stored in a way that survives an incident (ideally with a copy isolated from the main system). The key is not just to make backups, but to check that they can be restored: a backup that no one has tried to recover is a backup that may not exist on the day it is needed.

Device management

Rules on which equipment may process the organisation's data, updating of software and operating systems, automatic screen locking and control of personal devices if they are used for work. An outdated device is an open door that the policy must close with clear procedures.

Teleworking

Security conditions for working outside the office: secure connections, a ban on using unprotected public networks, safekeeping of documentation at home and separation between the professional and personal environment. Teleworking widens the company's perimeter and the policy has to keep pace with it, not ignore it.

Staff training

The best technical measure fails if the person using it does not understand it. The policy must provide for practical training: how to detect a phishing email, why sensitive data are not sent through personal channels, how an incident is handled. Security is a collective habit, not a piece of software.

Security breach management

An internal protocol that defines what a breach is, who it is reported to within the company, how it is documented and how to assess whether it should be notified. The GDPR provides, as a general rule, for notification to the supervisory authority within an indicative period of 72 hours where the breach entails a risk to people's rights (art. 33 GDPR), and communication to those affected where the risk is high (art. 34). Having the protocol written down in advance avoids improvising at the worst moment.

Technical measures and organisational measures

Art. 32 GDPR always speaks of technical and organisational measures, in the plural and together. It is not a rhetorical formula: they are two distinct families that need each other. The technical ones act on the systems; the organisational ones, on people and procedures. A policy that only takes care of one of the two leaves the door ajar.

The distinction is easy to see with examples. Encrypting a drive is a technical measure; the internal rule requiring every laptop leaving the office to be encrypted is organisational. The automatic backup system is technical; the procedure assigning one person responsibility for verifying that backups work is organisational. The following table sets out the main ones.

The most frequent mistake is to treat security as a purely IT problem. The best antivirus and the best firewall are bought, and it is forgotten that the link that fails most is not the machine, but the routine: the shared password, the email opened without looking, the unencrypted laptop in the car boot. Organisational measures are what turn technology into real protection.

Continuous risk-based assessment

One of the most widespread confusions is thinking that security is solved with an annual audit: everything is reviewed in January, a report is signed and the matter is forgotten until the following year. The GDPR does not work like that. Art. 32(1)(d) sets out a process for regularly testing, assessing and evaluating the effectiveness of the measures. The important word is process: something continuous, not an event with a date.

The correct approach is continuous risk-based assessment. The policy is reviewed when something that affects the risk changes, not when the calendar dictates. These are the usual triggers for a review:

• A new piece of software or provider that processes the organisation's data is brought on board.
• A new way of working opens up (teleworking, personal devices, a new site).
• The organisation starts processing a different type of data or a much larger volume.
• A security incident occurs, even if it did not escalate.
• The team structure changes: new hires, departures, role changes with their associated access.

This does not mean there are no periodic reviews: it means that a fixed date on the calendar is the minimum, not the system. Entrusting all security to an annual audit and disengaging for the other eleven months is exactly the scenario that accountability seeks to avoid. A living policy adjusts to the real pace of the business, because the risk also changes at that pace.

Checklist of a solid policy

To bring all of the above down to something actionable, here is a checklist of the elements that an information security policy should have resolved. It is not exhaustive —each organisation adds its own according to its risk— but it serves as a starting point.

• ✔ Role-based access defined, with granting and revoking when staff join or leave.
• ✔ Individual passwords and a second factor on critical access.
• ✔ Encryption of laptops, removable devices and sensitive communications.
• ✔ Backups that are periodic and tested for restoration.
• ✔ Screen locking and system updates as a routine.
• ✔ Teleworking rules written and known by the team.
• ✔ Basic security training for all staff.
• ✔ Breach protocol with clear responsibilities and deadlines.
• ✔ Duty of confidentiality signed by anyone accessing data.
• ✔ Art. 28 GDPR contracts with the providers that process data on the company's behalf.
• ✔ Policy review tied to the real changes in the business, not just to a date.

How Certix builds and maintains it

A security policy copied from a generic template has an underlying problem: it describes measures the company may not apply and omits the ones it actually needs. And since art. 32 GDPR requires the measures to be appropriate to the risk, a template that does not start from the real risk does not fulfil its function, however complete it may seem.

At Certix we build the information security policy from a real analysis of your organisation: what data you process, with what systems, who accesses them and which providers are involved. On that map, the technical and organisational measures corresponding to your level of risk are defined, documented in accordance with art. 32 GDPR and connected with the rest of the privacy work, from the Record of Processing Activities to the contracts with processors.

And we keep it up to date. When you bring on a tool, change provider or open a teleworking arrangement, the policy is reviewed to keep reflecting how you really protect information. You can see the full framework in our GDPR guide or speak directly to a consultant about your case.

Frequently asked questions

Is an information security policy mandatory?

The GDPR does not require a document with that exact name, but it does require the controller to implement technical and organisational measures appropriate to the risk (art. 32 GDPR) and to be able to demonstrate that it does so (art. 5(2), accountability). In practice, setting out those measures in an information security policy is the usual way of complying with that obligation and evidencing it. It is not an optional formality: it is the documentary support of a real legal obligation.

What is the difference between technical and organisational measures?

Technical measures act on the systems: encryption, backups, role-based access control, antivirus or automatic screen locking. Organisational measures act on people and procedures: password policy, staff training, duty of confidentiality, breach management protocol or teleworking rules. Art. 32 GDPR requires both together: one without the other leaves gaps, because the best encryption does not protect if staff do not know how to use it.

How often should the security policy be reviewed?

There is no fixed frequency imposed by the regulation. Art. 32(1)(d) GDPR sets out a process for testing and evaluating the effectiveness of the measures, and the correct approach is continuous risk-based assessment: the policy is reviewed whenever something relevant changes (new software, a new provider, a teleworking arrangement, an incident) and not only on a set date. Setting a rigid annual review and forgetting about it the rest of the year is precisely what the regulation seeks to avoid.

Do ISO 27001 or the ENS replace the GDPR security policy?

They do not replace it, but they are very useful reference frameworks. ISO/IEC 27001 is an international standard for information security management systems and the Spanish National Security Framework (ENS) is the mandatory framework for the public sector and its suppliers. Both help to structure the measures under art. 32 GDPR, but GDPR compliance is measured by the adequacy of the measures to the risk of the specific processing, not by holding a certification. Getting certified adds value; it does not exempt you from your own analysis.

In summary

The information security policy is the piece that turns a GDPR principle —the integrity and confidentiality of art. 5(1)(f)— into concrete measures that protect data day by day. It is not a document to be filed away, but the framework of rules that keeps security from depending on improvisation. It must combine technical and organisational measures appropriate to the risk (art. 32), be demonstrable (art. 5(2) and 24) and be reviewed as the business changes, not as the calendar dictates. If you want to know whether yours reflects how you really protect information, the next step is an individual analysis of your organisation.

Related reading

• Complete guide to the GDPR — the regulatory framework from which the security measures stem.
• Record of Processing Activities (RoPA) — the document where the security measures applied are described, processing by processing.
• Certix data protection consultancy — how the security policy fits into the consultancy work.

---

This content is purely informational and educational; it does not in any way constitute specialised legal advice. Applying the regulations to each specific case requires individual analysis.