The Word "And" Is Load-Bearing
When organisations read Rule 6 of the Digital Personal Data Protection Rules, they tend to land on the technical column and stop there. SSL certificate, check. Database encryption, check. Firewall rules, check. Compliance team notified, ticket closed.
That is a serious misread of the rule.
Rule 6 requires both technical and organisational measures. The conjunction is not accidental. The drafters were explicit that controls sitting only inside your infrastructure stack, however robust, do not exhaust your obligations under the framework. The DPBI, when it investigates a breach, will ask two separate sets of questions. The first set is about your systems. The second set is about your organisation, and in our experience, that is where companies are far less prepared.
What Rule 6 Actually Specifies
On the technical side, Rule 6 names four concrete requirements. Encryption of personal data in transit and at rest. Access controls on a need-to-know basis (Section 8(5) of the Act reinforces this at the fiduciary level). Audit logs capturing access and modification events. Periodic vulnerability assessments. Most mid-sized engineering teams can point to implementations of all four within a few weeks of reading the rule. That is not the hard part.
The organisational layer is where we see real gaps. Rule 6 expects a designated person or team to own compliance, not just know about it, but be formally responsible for it. It expects documented data handling procedures that staff can actually locate and follow. It expects staff to be aware of their data handling obligations, which means awareness is an ongoing activity, not a one-time onboarding checkbox. And it expects periodic review of the safeguards themselves.
Read together with Section 10 of the Act, which places responsibility squarely on the Data Fiduciary for verifying that processors handle data appropriately, the organisational requirements are not soft governance. They are the accountability scaffolding that makes your technical controls legally credible.
The Common Failure Mode
We see this pattern constantly: a technical team implements a genuinely solid security stack, encrypted at rest and in transit, strong access controls, a SIEM generating logs somewhere, and then declares the Rule 6 box ticked. The compliance item closes.
What nobody has done is document who has access to the personal data systems and why that access is justified on a need-to-know basis. Nobody has reviewed those access logs in six months. The vulnerability assessment was run during the initial deployment eighteen months ago and has not been repeated. No one can name the person who would be called at 2am if a breach were discovered, or what the documented escalation path to the board looks like.
This is not a hypothetical. It is a description of most organisations we speak with, including ones with genuine technical sophistication. The documentation trail that proves governance was actually exercised, that is what is missing.
The "Periodic" Problem
Rule 6 uses the word "periodic" deliberately without defining it. Our view is that this is intentional rather than an oversight. The DPBI will apply a reasonableness standard, and that standard will be calibrated to your context.
Annual vulnerability assessments may be reasonable for a small HR software company. They are almost certainly not reasonable for a payment processor running 10 million transactions a month, a healthtech platform storing diagnostic data, or any organisation that falls under the higher-risk categories the Rules contemplate. If your threat surface changes faster than your review cadence, "periodic" becomes a liability rather than a defence.
The practical implication: your review schedule should be explicitly documented and defensible against the question "given the volume and sensitivity of data you process, why was this frequency appropriate?"
What a Board-Level Programme Looks Like
The Ownership Structure
Every safeguard needs a named owner. Not a team, a person. When the DPBI asks who reviewed the access control policy and when, the answer cannot be "the IT department." Under Section 10, Data Fiduciaries cannot outsource accountability, only tasks.
The Review Cadence
In our experience, a defensible programme for a mid-to-large Data Fiduciary looks roughly like this: quarterly access log review with a documented sign-off, half-yearly vulnerability assessments with remediation tracking, annual refreshes of the Data Protection Impact Assessment (Rule 12), and a standing agenda item at the board or equivalent governing body for data protection status. That last one matters more than most boards realise, if a breach occurs and the board cannot show it received regular updates on the safeguard programme, personal liability exposure for senior management increases significantly.
The Documentation Test
Here is the grey zone that catches organisations off guard: a company can have perfect technical controls and still fail Rule 6 if it cannot produce records showing when those controls were last reviewed and by whom. The control existing is not the same as the control being governed. The DPBI will want to see the log of reviews, not just the configuration of the system.
Encryption at rest means nothing as a compliance artefact if you cannot show the access policy governing who holds the encryption keys was reviewed in the last quarter.
The Bottom Line
Rule 6 is not a technical audit, it is a governance test with a technical component. Organisations that treat it as a checklist for the engineering team will find the DPBI's investigation lands in the boardroom, not the server room.
Ready to map your Rule 6 obligations to a documented safeguards programme? Book a demo at truconsent.io/book-demo to see how truConsent helps Data Fiduciaries build and evidence the organisational layer.