Engineering teams read Rule 6 as a technical checklist and stop there. The organisational half — ownership, review cadence, documentation — is where the Board's questions actually land.
July 2026 · 5 min read
Most engineering teams read Rule 6, land on the technical column, and stop. SSL certificate, done. Database encryption, done. Firewall rules, done. Ticket closed, compliance item marked complete. In our experience, that's precisely the gap the Data Protection Board will probe after a breach — not whether the controls existed, but who owned them, when they were last reviewed, and whether the board of the company was actually told.
When organisations read Rule 6, they tend to land on the technical requirements and treat the reading as finished. That's a serious misread.
Rule 6 requires technical and organisational measures, together. That conjunction isn't incidental — the drafters were explicit that controls sitting only inside your infrastructure stack, however robust, don't exhaust the obligation. When the Board investigates a breach, it asks two separate sets of questions: one about your systems, and one about your organisation. In our experience, the second set is where companies are far less prepared.
On the technical side, Rule 6 lists four concrete requirements: encryption of personal data in transit and at rest, need-to-know access controls (reinforced at the Fiduciary level by Section 8(5)), audit logs of access and modification events, and periodic vulnerability assessments. Most mid-sized engineering teams can point to all four within a few weeks of reading the rule. That's genuinely not the hard part.
The organisational layer is where the real gaps sit. Rule 6 expects a designated person or team to own compliance — not simply be aware of it, but be formally responsible for it. It expects documented handling procedures that staff can actually find and follow. It expects staff awareness to be an ongoing activity, not a one-time onboarding item. And it expects periodic review of the safeguards themselves, not a one-time build.
Read alongside Section 10 — which places responsibility squarely on the Fiduciary for verifying its processors handle data appropriately — these organisational requirements aren't soft governance. They're the accountability scaffolding that makes your technical controls legally credible in the first place.
A technical team builds a genuinely solid stack: encrypted at rest and in transit, strong access controls, a SIEM generating logs somewhere. They declare Rule 6 done. The ticket closes.
What nobody's done: document who has access to the personal-data systems and why that access is justified on a need-to-know basis. Nobody's reviewed the access logs in six months. The vulnerability assessment ran once, at initial deployment eighteen months ago, and hasn't been repeated since. Nobody can name who gets the 2am call if a breach is discovered, or what the escalation path to the board actually looks like.
This isn't hypothetical — it describes most organisations we talk to, including ones with real technical sophistication. What's missing is the documentation trail that proves governance was actually exercised, not just that the controls exist.
Rule 6 uses "periodic" for reviews and assessments without defining a frequency. Our read: that's intentional, not an oversight. The Board will apply a reasonableness standard, calibrated to your context.
Annual vulnerability assessments might be reasonable for a small HR software company. They're almost certainly not reasonable for a payment processor running ten million transactions a month, a healthtech platform storing diagnostic data, or any organisation the Rules treat as higher-risk. If your threat surface is changing faster than your review cadence, "periodic" stops being a defence and starts being a liability.
The practical implication: your review schedule needs to be explicit and defensible against one question — "given the volume and sensitivity of what you process, why was this frequency appropriate?"
Every safeguard needs a named owner — a person, not a team. When the Board asks who reviewed the access-control policy and when, "the IT department" isn't an answer. Section 10 makes clear that Fiduciaries can outsource tasks, not accountability.
A defensible programme for a mid-to-large Fiduciary looks roughly like this: quarterly access-log review with a documented sign-off, half-yearly vulnerability assessments with remediation tracked to closure, an annual refresh of the DPIA (Rule 12), and a standing agenda item at board level for data protection status. That last point matters more than most boards realise — if a breach happens and the board can't show it received regular updates on the safeguard programme, personal liability exposure for senior management rises sharply.
Here's the grey zone that catches organisations off guard: a company can have technically perfect controls and still fail Rule 6 if it can't produce records showing when those controls were last reviewed and by whom. A control existing isn't the same as a control being governed. The Board wants the log of reviews, not just the current configuration of the system. Encryption at rest means little as compliance evidence if you can't show the access policy governing who holds the keys was actually reviewed last quarter.
Rule 6 isn't a technical audit — it's a governance test with a technical component attached. Organisations that treat it as a checklist for the engineering team will find the Board's investigation lands in the boardroom, not the server room.
The organisational half is exactly where our security posture assessment looks — safeguards mapped against Section 8(5), not just an encryption checklist.
30 minutes to talk through your specific data footprint — no obligation.
Book a Consultation