Access control and encryption for data

Why this matters

Protecting data comes down to two questions: who can get at it, and what they see if they get at it without permission. Access control answers the first, and encryption protects against the second. Analysts meet both every day, as users granted access to data, and increasingly as people who share data sets, build reports others can see, and move data between systems.

The exam asks you to compare privacy and protection strategies. This lesson covers role-based access and least privilege, row-level and column-level security, encryption at rest and in transit, access reviews, and sharing data outside the organisation safely. Masking, the third named strategy, has its own lesson next.

The lesson

Role-based access and least privilege

Access control decides who may read, change or delete which data. Two ideas underpin it.

Authentication proves who a user is, through a password, a token or, increasingly, multi-factor authentication, which combines something the user knows with something they have or are. Authorisation decides what an authenticated user may do.

Role-based access control (RBAC) grants permissions to roles, such as "sales analyst" or "finance manager", and assigns people to roles, rather than granting permissions to each person individually. When someone joins, moves or leaves, their role changes and their access follows. RBAC is easier to manage and audit than individual grants, which accumulate and are forgotten.

The guiding principle is least privilege: each user and each service account gets the minimum access needed for their work, and no more. An analyst who needs to read sales data does not need permission to change it, or to read HR data. Least privilege limits the damage from mistakes, compromised accounts and misuse. A related principle, separation of duties, splits sensitive tasks so no one person can complete them alone, such as the person who changes a financial figure not being the one who approves it.

Row-level and column-level security

Access can be controlled more finely than whole tables.

Row-level security restricts which rows a user sees within a table or report, based on who they are. A regional manager sees only their region's customers; a doctor sees only their own patients. One table and one report can then serve many users, each seeing only their entitled subset, which avoids maintaining separate copies for each group.

Column-level security restricts which columns a user sees. A support team may see customers' names and order history but not their payment details or date of birth. Sensitive columns can be hidden entirely, or shown masked.

Both are usually defined in the database or BI tool as rules tied to users' roles or attributes, and both must be tested: a report whose row-level security rule has a gap shows restricted data to everyone, without any sign that it is doing so.

Encryption at rest and in transit

Encryption transforms data into an unreadable form that can only be turned back with the correct key. Data is protected in two states.

Encryption in transit protects data as it moves across networks: between a user and a database, between systems in a pipeline, or to a cloud service. It is usually provided by TLS (Transport Layer Security), the protocol behind HTTPS. It prevents data being read or altered by anyone intercepting the connection.

Encryption at rest protects stored data: database files, disks, backups, files in cloud storage, and laptops. If a disk is stolen or a storage bucket is exposed, the data is unreadable without the key. It can be applied at the level of the whole disk, the database, individual files or specific sensitive columns.

The security of encryption depends on key management: keys must be stored separately from the data, protected, rotated periodically and available only to authorised systems. Encryption with the key stored beside the data protects very little.

Encryption protects against theft and interception, not against authorised users misusing their access, which is why it complements access control rather than replacing it. Hashing, a one-way transformation often used for passwords and for comparing values without revealing them, is related but different: a hash cannot be turned back into the original.

Access reviews and removing stale access

Access tends to accumulate. People change roles and keep their old permissions; temporary access for a project is never removed; accounts of people who have left stay active; shared service accounts gain more rights over time. This is sometimes called privilege creep.

Access reviews counter it: periodically, data owners or managers review who has access to what and confirm or remove each permission. Reviews are especially important for sensitive data and are often required by regulations and audits.

Supporting practices include:

• Joiner, mover, leaver processes that grant, change and remove access as people's roles change, with leavers' access removed promptly.
• Time-limited access for temporary needs, which expires automatically.
• Monitoring access logs for unusual activity, such as a user suddenly downloading far more data than normal.
• Avoiding shared accounts, so every action can be traced to one person.

For an analyst, the personal side is simple: request only the access you need, and ask for it to be removed when you no longer need it.

Sharing data outside the organisation safely

Analysts are often asked to share data with partners, suppliers, researchers or customers. External sharing moves data beyond the organisation's controls, so it needs particular care.

Good practice includes:

• Approval from the data owner, and a data sharing agreement stating what may be done with the data, for how long, and what happens to it afterwards.
• Minimisation: share only the fields and records needed, and prefer aggregated or de-identified data where it will do.
• Secure transfer: an encrypted, approved method, such as a secure file transfer service or a controlled access portal, rather than email attachments.
• Access controls on the shared data, with expiry dates where possible.
• Records of what was shared, with whom, when and under which agreement.

The question to ask before any external share is whether the recipient needs this exact data to do the agreed task, and the answer usually removes most of the columns someone first asked for.