Access Control Policy: What to Include

An access control policy provides rules and guidelines structuring who can access data and resources at an organization. It takes the form of a document offering a high-level overview, and is then implemented via more specific rules and procedures.

In this article, we’ll go over everything you need to include in an access control policy. For an example, we’ll refer to the access control policy of Loyola University Chicago.

What to Include in an Access Control Policy Document


Our example from Loyola University Chicago makes clear who the policy applies to (“faculty, staff, students, contractors and vendors”) and how it applies – specifically, when they connect to systems that deal with Loyola Protected Data.

The Scope section of an access control policy describes who and what the policy applies to. An access control policy can apply to employees, contractors, users, or customers – and it can apply differently to each of these groups. The rules governing an employee, for instance, might look very different from those that apply to an end user.

This section also covers what kinds of resources the policy applies to. You might make particularly sensitive data a class of its own, with tighter access rules protecting this information.

Scope also limits where and how the access control policy applies. Typically, an access control policy governs what employees do with company resources, for instance, but doesn’t apply when they use personal computers for non-work concerns.

The point of the Scope section is to make clear what your access control policy does and doesn’t apply to. If users aren’t sure, they’ll probably just assume the access control policy does not apply to them. And if the policy isn’t specific, they’re arguably right.


Example Purpose section from Loyola University Chicago.

The Purpose section tells readers why the access control policy exists. Usually, the goal is to protect sensitive information and other resources. However obvious that might seem, it never hurts to be perfectly clear what the goal of a policy is, so that you can be certain everyone understands the stakes and is on board with the policy.

Our example policy lays out two main goals. “To minimize potential exposure to the University resulting from unauthorized use of resources” is the first. This is all about reducing risk. By guarding against unauthorized access, the policy reduces risk of damage to the University.

The second goal of our example policy is “to preserve and protect the confidentiality, integrity, and availability of the University networks, systems, and applications.” These three terms – confidentiality, integrity, and availability – are common goals of information security policies. You don’t want anyone or anything stealing data, tampering with data, or making your resources unusable.


Our example from Chicago University Loyola doesn’t have a separate Responsibilities section, but it goes over this information at the start of its Policies section.

The Responsibilities section details who’s responsible for what under the access control policy. This usually breaks down into two types of responsibilities.

The owner of the policy writes and oversees the policy. The policy belongs to them, and they’re responsible for it. If you have questions about a policy, they’re likely a good person to ask.

In some cases, the same team owns and implements an access control policy. Just as often, one team owns the policy while another actually implements it. A company might have a chief security officer who sets policies and a separate team of IT administrators that actually handle access rights in practice. You might even have multiple teams handling different aspects of an access control policy.

This separation of duties ensures that no one person or team has total control over your access control system. Instead, responsibilities are shared so that both teams must work together to administer the system. That way, one person acting alone can’t break the rules, intentionally or accidentally.

In our Loyola example, responsibilities do not have their own distinct section. However, they’re the first item in the policy section, which details who approves access, how access controls are implemented in practice, and who handles account changes.

A Responsibilities section can also outline the responsibilities different parties have on a given system. You can see an example of this approach in the University of Sheffield’s access control policy.


Let’s get to the meat of it: the Policies section lists the individual policies that comprise the access control policy in full. The policies you decide to include are highly dependent on the organization and its security needs. However, there are some common components you’ll want to consider.

The Need-to-Know Principle

The need-to-know principle dictates that users should only have access to whatever resources they need to perform their job. If someone doesn’t need access to a category of sensitive data, they shouldn’t be allowed access to it.

Because the need-to-know principle significantly reduces exposure to sensitive data, it is the foundation of many access control policies. The more people who can access something, the greater the risk that something bad could happen to that data.

Even if you think you can trust 100 employees with access to your customers’ billing information, any one of their accounts could be compromised at any time. And if any one of those 100 accounts are compromised, you would have a serious breach on your hands.

When it comes to sensitive resources, you should limit access to those people who really need access. The fewer people who have access, the less risk there is of a security breach.

Password Policy

A password policy establishes rules around what passwords are acceptable, and how users can handle their passwords. If you’ve ever had to make a password a certain length or include special characters, you’ve encountered the hard rules of a password policy.

These hard rules exist to make it tougher for hackers to crack passwords via a brute force attack. A four-digit numeric password can be cracked in a matter of seconds. Eight digits, including lowercase and uppercase letters, as well as special characters, takes much more time and computing power to figure out.

Password policies often include other rules, as well. They might require users to change their passwords periodically, or provide guidelines never to share passwords via email.

Hard rules, such as forcing people to include special characters, are relatively easy to enforce: the system simply does not allow users to create a non-compliant password. Soft rules often require regular training to make sure people are on board.

Many password policies these days include multi-factor authentication. One common approach is to require users to submit a one-time code texted to their phone number. This makes it much, much harder for an attacker to gain unauthorized access to a system via cracking or phishing. The password alone simply won’t cut it.

Physical Access Policy

A physical access control policy who can access data storage centers, server rooms, physical records, and any other physical locations or resources.

Different locations require different levels of access control. An office might be open to all employees, as well as approved guests. A physical data center handling sensitive information might be restricted to a select group of employees, and enforced more strictly than the office entrance.

Our example from Loyola includes a list of rules that illustrate some common aspects of a physical security policy.

Remote Access Policy

A remote access policy structures how users can interact with an organization’s resources, while not at physical locations operated by said organization. Now that so much work takes place online, clear policies structuring remote access are more important than ever.

A remote access policy might require users to use a company VPN of follow other rules to ensure they are accessing the network from a secure device, using a secure connection. Often, that means using a device provided by the company itself.

For particularly sensitive resources, it often makes sense to disallow remote access entirely – except, perhaps, by key personnel, and with extra precautions in place.

Audit Policy

To ensure your access control policy is working as expected, you’ll want to periodically audit access controls and user rights. Everyone makes mistakes, and even a well-run access system will eventually slip up.

When users change roles, for instance, they gain whatever new permissions they need to handle their new responsibilities. But administrators don’t always remember to check for permissions they no longer need. By periodically auditing your access controls, you can ensure it stays in line with your access control policy.


An example Adherence section from Loyola University Chicago’s Access Control Policy.

The Adherence section outlines what happens if the access control policies are not followed. Sometimes called “Enforcement” instead of “Adherence”, it covers what happens when people don’t follow the rules.

A policy with no enforcement is a weak policy. Employees won’t have a strong reason to follow it. Some will, sure, but others might cut corners, especially if it makes their work easier.

To ensure adherence, any security policy should also include some form of training. If you don’t reinforce the policy, people are likely to lose track of the rules. For best results, security training should happen on a recurring basis, so that employees don’t forget your policies over time.


You should also include a brief Questions or Contact section, giving readers a clear point of contact in case they’re not sure about anything they just read. A confused user won’t be able to follow the policy effectively – so make sure people know who to talk to if they have any questions about your access control policy.


A good access control policy is a living document, and should be kept up-to-date. A History section listing updates and audits builds trust that the policies are actively maintained.


An access control policy on its own doesn’t do much. For it to be effective, it must be supported by methods, procedures, and some form of access control model.

Methods and procedures exist at the granular level of implementation. Your password policy might offer rules and guidelines on what a password should look like, but actually setting a password is a procedure in itself.

An access control model provides the structure in which your policies are enacted via processes. Under a role-based access control model, for instance. permissions are granted to specific roles, which individual users are then assigned to. You can read more in our complete guide to access control models.


The contents of your access control policy depend largely on the needs of your organization. Hopefully this article gives you an idea of what you should include when writing an access control policy document.

About the Author

Find Michael on LinkedIn

Michael X. Heiligenstein

Michael X. Heiligenstein is the founder and editor-in-chief of the Firewall Times. He has six years of experience in online publishing and marketing. Before founding the Firewall Times, he was Vice President of SEO at Fit Small Business, a website devoted to helping small business owners. He graduated from the University of Virginia with a degree in English and History.