Data protection law rarely prescribes specific technology. It requires appropriate security and leaves it to the company to define it. Technical and organisational measures are the answer — and they are what gets examined after an incident.
The protection goals
The Swiss Data Protection Ordinance names confidentiality, availability, integrity and traceability as goals of data security. Article 32 GDPR names, among others, pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience of systems, rapid restoration after an incident, and a process for regularly testing effectiveness. Both frameworks tie appropriateness to risk, the state of the art and cost.
Technical measures
For a typical SaaS application: encryption in transit and at rest, strong authentication with multi-factor and single sign-on, tenant separation at database level, for example with row-level security, roles and least privilege, logging of security events, regular backups with tested restoration against defined RPO and RTO, hardening and updating dependencies, pseudonymisation where possible and a penetration test before major releases.
Organisational measures
Responsibilities for data protection and information security, directives on handling data, staff training, a joiner-mover-leaver process that revokes access, contracts with processors, a prepared process for data breaches and regular review of whether the measures work. In practice organisational gaps cause incidents more often than technical ones.
Documentation
TOMs must not only exist but be described. Customers request them as an annex to the data processing agreement, auditors and authorities ask for them, and the record of processing activities should describe them at least generally. A good TOM description is concrete enough to be verifiable and general enough not to need rewriting at every configuration change.
Common mistakes
A TOM document from a template claiming measures that do not exist. Backups whose restoration was never tested. Admin rights for everyone because it is easier. And measures that apply to the main system but not to the side systems where the same data sits as an export. We check TOMs against actual implementation in our GDPR audit for SaaS.