Data Security & Technical Organizational Measures (TOMs)

A recap of the Pyxos masterclass with Aben Pagar and Skanda Reddy.

Most security failures under the PDPL do not happen because an organization lacked controls. They happen because the controls lived in a policy nobody operationalized, or because they were calibrated to the wrong risk. That was the throughline of this masterclass with Aben Pagar and Skanda Reddy of Konexo, the consulting arm of Eversheds Sutherland: technical and organizational measures are not a checklist you adopt once, but a discipline you calibrate and keep alive as threats, systems, and standards move.

The legal floor is quickly stated. Article 19 of the PDPL and Article 23 of the Implementing Regulations require appropriate organizational, administrative, and technical measures whenever personal data is processed, and in Saudi Arabia those sit alongside a second regime: the National Cybersecurity Authority's controls, with enhanced requirements for health and credit data. But the session spent little time on the statute and most of it on a harder question: what do you actually do with all of that.

The answer that ran through the session was counterintuitive for a compliance topic. Do not over-engineer. Most organizations already have a control matrix; the task is rarely to build one from scratch and almost always to revisit it with the right people. Applying every available control across the board, Reddy argued, is both meaningless and overkill, because the risk of a furniture purchase is nothing like the risk of a cloud analytics platform. Calibration to risk, not the maximum number of controls, is the work. The session set out a full control baseline and a five-step lifecycle for building and maintaining those measures, which are best taken from the recording and the takeaways.

That makes risk identification the step that matters most, and it is a judgment call rather than a technical one. Of the lifecycle's stages, Pagar was blunt that this is where a privacy professional should spend the most time, and that the judgment has to align with the CEO or board's risk appetite. Some organizations accept zero non-compliance risk; others document and accept a defined level of risk to keep pace with innovation. Neither posture is wrong. What matters is that the choice is deliberate, signed off at the right level, and written down, because a regulator will look at how the thinking was done.

Asked what fails most often in practice, Pagar did not hesitate: access, access, access. Over-broad rights granted for convenience, the joiners-movers-leavers process going unmonitored, privileged break-glass accounts left unwatched, and phishing as the social-engineering threat that still lands. The remedy is to build access from the bottom up, by what a role genuinely needs, rather than top-down master access handed down because someone is senior. Reddy added the detail that catches organizations out: the leaver account nobody deprovisions, which is exactly the gap an attacker exploits.

Pagar made a point worth holding onto: balancing risk against cost is a judgment built over years of knowing your own business, and it is not one a tool makes for you. The aim of automation in this discipline is not to replace that judgment but to clear the manual work around it, so the experience of the people making the call goes further. The calibration stays human; the burden does not have to.

The session closed where it opened: do not be a one-person army. Security under the PDPL is cross-functional by nature. Legal owns the nuance of the law, IT and cyber implement the controls, and the privacy function convenes the two. The closing message was not a new control to buy. It was to revisit the matrix you already have, with the right people in the room, calibrated to the risk you actually carry.