by Tim Marley
We have spent the last two weeks in the CIS Controls series talking about data management and data inventory. Knowing what you are responsible for. Knowing where it lives and how it moves.
This week, Control 3.3, is about deciding who gets to touch it.
The formal term is a data access control list. I had the same reaction you probably just did. But access permissions? That we understand. Who can see what. Who can change what. Who should not be in certain places at all.
Need to know
The principle behind this control is simple: people should only have access to the data they need to do their job. Nothing more.
In practice, most organizations default to the opposite. Access gets granted because it is easy, or because someone asked, or because opening things up was simpler than thinking it through. Nobody made a bad decision. It just never got revisited.
That is what I usually see in the field. Not malicious exposure. Just drift.
A folder that was shared broadly because it was faster to open it than configure it. A contractor who still has access to systems they have not touched in two years. A departing employee whose permissions were never reviewed because nobody thought to check.
The gap between who has access and who should have access is where most organizations find their risk.
Roles, not individuals
The most practical way to manage access at any scale is to stop thinking about individuals and start thinking about roles.
This is called role-based access control, or RBAC. The idea is straightforward. Rather than deciding what each person can access one by one, you define what a given role requires and assign access based on that. An accounts payable clerk gets what accounts payable clerks need. A sales manager gets what sales managers need. When someone joins the organization, changes roles, or leaves, the adjustment is clean because the logic was already defined.
Without that structure, access tends to accumulate. Someone gets promoted and picks up new permissions. The old ones never get removed. Five years later, they have access to systems from three jobs ago and nobody remembers why.
RBAC does not eliminate that problem on its own. But it gives you a framework to manage against instead of just reacting.
Who actually owns this decision
Here is something that gets misunderstood regularly. IT does not decide who gets access to what. They are the custodians. They implement the decision. The decision belongs to the business.
The manager of the accounting department knows whether a new hire needs access to the general ledger. The HR director knows what systems a recruiter should be able to reach. The data owner, whoever is responsible for that category of information, is the one who should be making the call.
IT’s job is to execute it correctly and consistently. That is an important distinction, because when it gets blurred, one of two things tends to happen. Either IT becomes a bottleneck because every access request requires a judgment call they are not positioned to make. Or access gets granted too broadly because it is easier than asking questions nobody wants to answer.
The process problem
If the data owner is making the access decision, there has to be a reliable way to communicate it to IT. And this is where a lot of organizations quietly fall apart.
The most common method is email. Someone sends a message saying the new hire needs access to the shared drive, IT makes the change, and everyone moves on. Quick. Simple. And also undocumented, inconsistent, and almost impossible to audit six months later.
Email works until it doesn’t. The request gets misread. The scope is unclear. The message gets buried and the access never gets provisioned. Or it gets provisioned too broadly because the request was vague and nobody followed up.
A more reliable approach is a defined process. That could be a form, a ticket in your helpdesk system, or a structured request that captures the specific access being requested, the business justification, and the name of the person authorizing it. The format matters less than the consistency. What you want is a record that shows who requested what, who approved it, and when it was done.
HR is often the right trigger for this process. A new hire should generate an access request as part of onboarding. A promotion or department transfer should generate a review of existing permissions and a request for whatever the new role requires. A departure should generate a revocation. When access changes are tied to HR events rather than ad hoc requests, fewer things fall through the cracks.
That does not mean HR manages access. It means HR activity drives the workflow that prompts the right people to make the right decisions at the right time.
Permissions are not set-and-forget
Even a well-designed access model will drift over time if nobody is reviewing it. Roles change. People leave. Responsibilities shift. What was appropriate access six months ago may not be appropriate today.
Periodic access reviews exist to catch that drift before it becomes a problem. The idea is straightforward: at defined intervals, data owners and business managers review who has access to what and confirm it still makes sense. Accounts that no longer have a business justification get removed. Access that has crept beyond what the role requires gets trimmed back.
This does not have to be a massive undertaking. For smaller organizations it may be a quarterly conversation. For larger ones with more complex environments it may be more structured. The frequency matters less than the consistency.
The former employee whose account is still active six months after their last day is not a hypothetical. It is one of the most consistent findings I see in the field. In some cases, the consequences are minor. In others, the access was never revoked, the person knew exactly where the sensitive data lived, and the organization spent the next year dealing with the fallout.
Periodic review is how you catch that before it catches you.
A place to start
If you built a data inventory last week, you already have what you need to begin this conversation.
Go back to that list. For each category of sensitive data, ask two questions. Who legitimately needs access to do their job? And who currently has it?
The gap between those two answers is where the work is.
Start with your most sensitive data. Apply least privilege: give people access to what they need, and nothing more. And while you are at it, ask whether you have a defined process for how access gets requested, approved, and revoked. If the answer is “someone sends an email,” that is worth fixing before anything else.
Why this matters beyond an audit
Access control comes up in compliance conversations, but its value is practical before it is regulatory.
When you limit who can reach sensitive data, you limit the damage if something goes wrong. A compromised account with narrow permissions does far less harm than one with broad access. That is not a framework argument. That is just risk management.
We will get into retention and disposal over the next couple of weeks. But access control is one of those foundational pieces where getting it right early makes everything downstream easier. It is a lot simpler to manage data through its lifecycle when you know exactly who has been in it.
Tim Marley is a cybersecurity and risk management executive with more than 20 years of experience in IT audit, compliance, and information security. Tim helps organizations strengthen their security posture, navigate regulatory requirements, and manage complex risk with clarity and confidence.
