IT compliance is the discipline that ensures an organisation's systems meet the body of legal, sector-specific and contractual obligations that apply to them. It is not a paperwork exercise: it is the translation of legal requirements into concrete technical controls — encryption, access logs, retention policies — that can be demonstrated to a supervisory authority. In the case of personal data, that requirement has a specific name: the GDPR, or General Data Protection Regulation, which is exactly the same text as the Spanish-language RGPD (Reglamento General de Protección de Datos).
A common misconception is worth clearing up: GDPR and RGPD are not two separate regulations. They are the same Regulation (EU) 2016/679 — one named in English, the other in Spanish. In Spain, the regulation is further developed and complemented by Organic Law 3/2018 on the Protection of Personal Data and Guarantee of Digital Rights (LOPDGDD), which introduces specific provisions such as the regulation of digital rights in the workplace.
GDPR principles that a system must embody
Article 5 of the Regulation establishes six principles that cease to be theoretical the moment a system is designed. Data minimisation requires collecting only the data that is strictly necessary: a database storing a national ID number "just in case" already fails this test. Purpose limitation prohibits reusing data collected for one purpose for a different one without a new legal basis. Storage limitation requires deletion or anonymisation once data is no longer needed, which translates into automated retention policies. And integrity and confidentiality mandates appropriate technical security. Article 25 adds data protection by design and by default: privacy is not bolted on at the end of a project — it is built into the architecture from the outset.
Privacy by design in technical practice
Translating "by design" into real engineering means making concrete decisions. Pseudonymisation separates direct identifiers from behavioural data so that a partial breach cannot re-identify individuals. Effective anonymisation — genuinely irreversible, not merely deleting the name column — takes data outside the scope of the Regulation entirely. Encryption at rest and in transit, combined with proper key management, guards against unauthorised access. And role-based access control (RBAC) grounded in the principle of least privilege ensures that each person sees only what their role requires, while producing an auditable log of every access.
The distinction between pseudonymisation and anonymisation is more than terminological and is frequently confused. Pseudonymised data remains personal data under the GDPR, because a key exists that allows re-identification of the data subject; the individual is protected only from those who do not hold that key. Truly anonymised data, by contrast, no longer permits re-identification by any reasonable means and falls outside the scope of the Regulation. The practical consequence is significant: many organisations believe they have anonymised data when they have only pseudonymised it, and they remain subject to every obligation under the law. Robust anonymisation requires techniques such as generalisation, suppression of quasi-identifiers or differential privacy, and must resist re-identification attempts by cross-referencing with other data sources — the risk that a postcode, a date of birth and a sex can uniquely identify a specific person is well documented.
Systems auditing and reference frameworks
An IT compliance audit measures the actual state of systems against a recognised control framework. The most widely adopted framework for information security is ISO/IEC 27001, which defines a certifiable information security management system (ISMS) and, in its annex of controls, specific practices. For privacy specifically, the extension ISO/IEC 27701 adds the controls of a privacy information management system (PIMS). In cloud environments, frameworks such as the CIS Benchmark and the Cloud Controls Matrix translate controls into verifiable configuration settings. An audit produces evidence: configuration screenshots, log extracts, role matrices and processing records.
The value of relying on these frameworks is that they convert abstract legal obligations into verifiable, repeatable controls. The GDPR requires "appropriate technical and organisational measures" — a deliberately open-ended phrase. ISO 27001 translates that requirement into specific controls covering access management, encryption, backups, incident management and business continuity, each with its associated evidence. When a supervisory inspection or a client audit arrives, the organisation does not improvise: it presents an inventory of controls, their implementation status and proof that they are functioning. That is the difference between claiming compliance and demonstrating it. The audit must also be recurring: a control that was working a year ago may have been disabled after a migration, and only a periodic review will catch that before it becomes a breach.
Steps towards an IT compliance programme
- Inventory processing activities. Build and maintain the Article 30 record of processing activities — the foundation for everything else: what data, for what purpose, where it is stored and to whom it is disclosed.
- Determine the legal basis. Each processing activity requires one of the six bases in Article 6 (consent, contract, legal obligation, vital interest, public task or legitimate interest).
- Assess risk. Where processing is likely to result in high risk, carry out a Data Protection Impact Assessment (DPIA) in accordance with Article 35.
- Implement technical controls. Encryption, RBAC, audit logs, encrypted backups and automated retention policies.
- Prepare for breach response. Define the procedure for notifying the supervisory authority within 72 hours (Article 33) and for communicating with affected individuals where required (Article 34).
- Designate a DPO where applicable. A Data Protection Officer is mandatory for certain types of processing (Article 37) and advisable in many other situations.
Common mistakes
The most recurring mistake is confusing having documentation with actually complying: a flawless privacy policy on a website is worthless if the system continues to retain data for ten years without any legal basis. The second is treating consent as a catch-all basis when, in practice, it is the most fragile and revocable of all legal bases; a contract or legitimate interest is often more solid and appropriate. The third is overlooking processors: every cloud provider or SaaS supplier that processes data on behalf of the organisation requires an Article 28 contract and, if they are outside the European Economic Area, documented transfer safeguards. The fourth is discovering the breach notification procedure on the day a breach actually occurs, with the 72-hour clock already running.
Comparison of applicable frameworks
| Framework / standard | Scope | Nature | Certifiable |
|---|---|---|---|
| GDPR (EU 2016/679) | Personal data | Mandatory | No (it is law) |
| LOPDGDD (LO 3/2018) | Personal data in Spain | Mandatory | No (it is law) |
| ISO/IEC 27001 | Information security | Voluntary | Yes |
| ISO/IEC 27701 | Privacy management (PIMS) | Voluntary | Yes (extension of 27001) |
Frequently asked questions
Are GDPR and RGPD different regulations? No. They are the same Regulation (EU) 2016/679: GDPR is its name in English and RGPD is its name in Spanish. An organisation that complies with one automatically complies with the other.
How large are GDPR fines? The GDPR provides for fines of up to 20 million euros or 4% of total worldwide annual turnover — whichever is higher — for the most serious infringements. Actual penalties are scaled according to severity, intent and measures taken.
Does every organisation need a DPO? No. A Data Protection Officer is mandatory for public authorities and for those carrying out large-scale systematic monitoring of individuals or large-scale processing of special categories of data. Outside those situations, appointing one is voluntary, although often advisable.
Does ISO 27001 certification guarantee GDPR compliance? Not automatically. ISO 27001 provides a solid security foundation and demonstrates diligence, but GDPR compliance additionally requires specific privacy controls that are better addressed by ISO 27701.
What is the deadline for reporting a data breach? Article 33 of the GDPR sets a maximum of 72 hours from the moment the controller becomes aware of the breach to notify the supervisory authority, unless the breach is unlikely to result in a risk to the rights and freedoms of individuals. Where the risk is high, Article 34 further requires communication to the affected data subjects without undue delay. Having the procedure rehearsed in advance — who decides, what is documented, how to contact the authority — is what makes it possible to meet that deadline under the real pressure of an incident.
Does GDPR apply to a company outside the European Union? Yes, when it offers goods or services to individuals in the EU or monitors their behaviour, pursuant to the extraterritorial principle in Article 3. The location of servers is not the determining factor: what matters is the audience to whom the data relates.
At Summum Sistemas we approach IT compliance as engineering backed by legal expertise, not defensive paperwork. The GDPR does not penalise organisations for suffering an incident; it penalises them for failing to implement the reasonable measures that would have prevented or contained it. That is the practical key: a well-constructed compliance programme converts each legal obligation into a verifiable technical control — a log that can be produced on demand, a retention policy that runs automatically, a signed Article 28 contract with every processor — so that, when an audit or a breach occurs, the organisation can demonstrate diligence with evidence rather than good intentions. Compliance is not having the documents; it is being able to prove that the system does what the documents promise.