Security Controls and Data Protection Framework

The terms below are the ones that recur when deciding which controls a system needs and how far they have to reach. They are definitions rather than procedures; the concrete controls they select between are listed under Data in transit and at rest.

Types of control

Preventive controls stop an unwanted action before it happens. Encryption, access control, authentication, network segmentation, input validation and firewalls are all preventive: they change what is possible.

Directive controls shape behaviour rather than constraining it. Security policies, acceptable use policies, data handling guidelines, password policies and awareness training are directive: they change what people intend to do, and are only as effective as the enforcement behind them.

The distinction matters when assessing a control set. A framework made largely of directive controls looks comprehensive on paper and prevents nothing; one made only of preventive controls leaves people improvising around the gaps.

Storing versus executing

Two different permissions are routinely conflated.

Who may store data is a question about persistence: which principals may write to which stores, under what classification, retention and encryption requirements, and with what backup obligations.

Who may execute data is a question about code: which principals may cause stored bytes to be run. Code signing, application allow-listing, execution permissions on storage and sandboxed runtimes all answer it. The pattern to watch for is a system where an upload destination and an execution path overlap — a store that anyone may write to and something else will later run.

Data minimisation

The cheapest way to protect data is not to have it. Two strategies follow.

Reduce distribution — limit how far a sensitive value spreads. Centralise the authoritative copy, grant access on a need-to-know basis, expose data through an API instead of copying it into each consumer, substitute tokens for the real values where the consumer does not need them, and keep an inventory that says where each dataset actually lives.

Reduce persistence — limit how long it is kept and where. Automated deletion at the end of a retention period, ephemeral storage, session-scoped processing, just-in-time access, tokenization and masking all reduce the window in which a store is worth attacking. See vaultless tokenization for the case where a value must keep its format while losing its meaning.

Separation of duties

Separation of duties — also called segregation of duties — divides critical functions and privileges among multiple roles so that no single identity holds enough control to act unilaterally or to cover its tracks. In practice:

• No single user or role holds full administrative access across all resources.
• Permissions are broken down along the lines of actual responsibilities, and granted at the least privilege that lets the job be done.
• Data is segmented across security boundaries, with different encryption keys for different categories and stricter controls around the most sensitive segments.
• Production, development and test environments carry different access levels, and access to one does not imply access to another.

The benefit is not only that a malicious insider is constrained. It also limits how far a single compromised credential reaches, produces audit trails that mean something because the actor and the approver are different principals, and makes lateral movement harder because each step needs a different set of permissions.

Blast radius

Blast radius is the scope of impact when an incident does occur — how many systems, how much data, how many users, how many regions, and what it costs the business. It is the quantity that segmentation, isolation, per-tenant or per-category key separation, containerisation and service-level boundaries all exist to reduce. Estimating it is a useful design exercise even when no control changes as a result: an answer of “everything” is itself the finding.

Single point of failure

A component whose failure takes the whole system with it. They are not only technical:

• Technical — one database, one gateway, one region.
• Process — one approval step with no alternate path.
• People — one person who holds the knowledge or the access.
• Location — one datacentre, one office, one jurisdiction.

Redundancy, high availability, load balancing, documented disaster recovery and cross-training are the corresponding mitigations. As with blast radius, the value is in naming them: an undocumented people-SPOF is discovered during the incident.

Applying the framework

The sequence is unremarkable and works: identify the sensitive data and map its flows, assess the controls already in place and the gaps, select and design controls against the gaps, deploy them with monitoring and training, then audit, test the incident response and revise. What makes the difference is that each pass starts from the current inventory rather than the previous document — controls decay when the data moves and nobody re-maps it.

Four principles hold across all of it: layer controls so that no single one is load-bearing; grant least privilege and time-bound it; protect data at the source rather than at each consumer; and reassess on a schedule rather than after an incident.