Managing Data Access on Windows Fileservers: Assignment of Users

Step 4: Assignment of Users

Assignment of Users to Active Directory Security Groups

The fourth step in managing data access on Windows fileservers is properly assigning users to active directory security groups. If this is not done correctly, it can lead to unauthorised access to shared data and critical losses to your IT infrastructure

Security should be implemented through well-defined groups. Users should be assigned to groups and the groups granted the rights to access the folders.

This way, the users enjoy access to the folders based on the group privileges. Since it’s easier to maintain the integrity of your systems by managing groups than individual users, users should never be granted access rights to folders directly.

In most cases, ordinary users should not be assigned Full Control permissions. This permission level is a huge security risk because users can misuse it. Worse still, if it gets into the hands of attackers, it can lead to heinous consequences.

It is recommended to implement a least privilege permission level and minimise the permissions required to allow access. Usually, Read and Write permissions are sufficient to allow users to complete most tasks.

The basis for the assignment of users to folders is a rather complex question and answer game.

For each folder that needs to be protected with permissions, ask the person responsible for the data which users should receive which access rights. Please follow the processes described in the previous chapter.


You can use a permissions matrix to help in gathering necessary data and providing documentation for the permissions assigned to users. These matrixes can easily be made using an Excel table.

For each folder that needs its own permissions, make a row. In the columns, the users that have access to the folder will be recorded. The necessary permissions can be specified with a “W” for “Write” permissions and an “R” for “Read” permissions.

With this matrix as a starting point, you can plan and create security groups within the Active Directory and assign users to the appropriate groups.

These tables should ideally be administrated directly by the person responsible for the data in question (the data owner).

A matrix should be created and maintained for each department. Otherwise, a very large matrix should be used to administrate the permissions for all departments, in which case other persons should not be allowed to change the content of cells.

Importantly, once the matrix has been created, it is essential to implement a continuous authorisation process in which the assigned permissions are audited. This way, the data permission integrity will not be compromised.

If an authorisation process is not adopted, it can make the permissions to revert to their previously chaotic state and cause security risks, such as privilege creep.


An employee from Human Resources needs to read the vacation lists from Sales. This is stored in: “\\Department\sales\planning”

So that the HR employee does not gain access to the entire “Sales” folder and subfolders, he/she must first be put into the LIST Group for that folder. By using this step, the HR employee can open the “Sales” folder, but cannot read or change data. At that point, the HR employee must be assigned to the group “FG Sales Planning R”, which granted them “Read” permission for the subfolder. That employee will then be able to access the subfolder planning and read the data within.

In short, this “LIST” permission allows someone to “take a walk” through a closed area.

No Assignment of Individual Permissions

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02_Artboard 4.png

As earlier mentioned, you should never assign individual permissions to users. Using security groups to control access to critical data minimises the risks of direct permissions and ensures easy management.

However, the permission structure is not always as simple as the company structure. Often, it will be necessary to create permissions that originate outside of the data area.

For instance, it might be necessary for an HR employee to have access to the company’s personnel planning table, which is located in the data area of “Sales”.

In this case where sensitive information should only be accessed by a specific individual, the IT administrator should not assign the HR employee to the Sales group. Instead, the administrator should provide that employee with permissions for this folder as an individual or even provide only the permission for a single file.

Failing to assign rights well will have fatal consequences:

  • If a search is to be done to find out where an uncooperative user has access permissions, it would have to be conducted on all servers, which is a difficult and demanding task.
  • If an employee changes their area of work or department, it is no longer easy to know which permissions must be changed. If there is no documentation, no one will know what permissions that employee had.
  • If an employee leaves the company and their account is deleted, then an “SSID corpse” (an unreadable identification code no longer be associated with a person) will remain in the ACL list of the folder.

Download Checklist

Click here to download a checklist that will assist you with assigning users to active directory security groups.


In the next step, we’ll talk about implementing proper tooling and reporting.

Managing Data Access on Windows Fileservers: Assignment of Groups

 Step 3: Assignment of Groups

Assignment of Users to IT-Objects (Folders)

The third step in properly managing data access on Windows fileservers is to use security groups for assigning permissions.

A group consists of a set of users who have been granted certain permissions. This way, implementing and managing permissions become easier rather than assigning permissions to individual users.

To give users access to data (whether the data consists of email distribution lists, file structures on file servers, or SharePoint spaces), administrators can create groups and assign them the necessary permissions.

For example:

You can give an employee from the Sales Team direct access to the folder “\\departments\sales” with “Full Control” permission. Doing so will allow the user to read the data and make changes to it. But what else will that user be able to do? With “Full Control” permission, that employee can also assign permissions and revoke them. Potentially, he/she could revoke access permissions for all other users, including administrators. Therefore, assigning such individual permissions is not considered a best practice and can lead to administrative nightmares. It is recommended to assign permissions via Active Directory groups. What if this user only needs permission to read data? Should this access be the same for each individual member of the sales team?

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-08.png

Assignment of General Security Groups to IT-Objects (Folders)

The usual, though incorrect, approach for creating permission structures is as follows:

A permission group is created for a department (e.g. Sales). At the same time, data areas will be created (e.g. file services, SharePoint spaces, and mail distributions).

The group “Sales” will then be assigned to these data areas. For example, this group gets “Write Access” permission for the file server folder “Sales” and “Read” permission on the web server. The mail distribution group is also taken care of using this authorisation group.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-03.png

Next, we are faced with the following challenges:

  • The managing director would like to have access to “Sales”, but does not want to receive email from that group. Should the managing director be automatically put into the “Sales” group?
  • A trainee starts in “Sales”. He does not need access to mail distribution, but only requires “Read” access to the data areas. What permissions should he be given?
  • An employee from Human Resources needs “Read” access to a subset of the data area, but not to the web server. How will we proceed in this case?

In all the above cases, the simplest approach is no longer viable due to the following dilemma:

The permission groups should be constructed on the basis of the organisation’s structure, not on the demands and requirements of the data objects.

Permission Groups vs. Secure Objects (Folders)

The solution for the problem described above is as follows:

For each IT object, (in our example, each folder in the file system), access requirements must be defined. For all underlying objects, (in this case, more folders and files), this will be done implicitly through inheritance of permissions. This principle means that at least one security group must be created within the Active Directory for each object requiring permission (e.g. each folder).

This assignment of dedicated permission groups to each folder with permissions has all the desired benefits for daily operations and reports.

For each folder, it is possible to say exactly who has which permissions and access to the data in said folder, such as the users who are members of these particular permission groups.

Furthermore, we know what a user’s permissions will be thanks to the uniqueness of the assignment of an object (folder) to a permission group.

It is important to give the security groups succinct and intuitive names. With a proper naming approach, the permissions can easily be associated with their specific groups, making administration easier.

You can also nest security groups (add groups to other groups) to lower the number of permissions that are required to be awarded to users or groups individually.

It can be said that a 1:1 relationship exists between the objects (our folders) and the groups within the Active Directory, while a many:many relationship exists between the users and permission groups.

For the moment, we will ignore the fact that different groups are created for “Read” and “Write” permissions.

The below diagram shows how this works:


Different Permission Groups for One Folder

For our example, we will create three security groups within the Active Directory for each folder that requires permissions:

  • A group for the award of LIST permissions
  • A group for the award of READ Permissions
  • A group for the award of WRITE Permissions

The below screenshot shows the three permission groups for the folder “\\departments\Sales”:

“Read” permissions are assigned when a user only needs to read files within a folder. For example, all public information about a project in the folder “Project Office” or all lists with sales prices in the folder “\\departments\Sales\Items” would be covered under “Read” permissions.

“Write” permissions will be awarded only if a user needs to alter files. It is important to keep in mind that assigning “Write” permissions also gives the user the permission to delete.

In the two examples above, “Write” permissions would be assigned to the staff members in project management or the project office who create and maintain information, as well as the staff members from the sales team who specify the sales prices based on internal calculations.

List permissions are required when a user needs rights to the folders deeper down in the file tree, but he does not have “Read” or “Write” permissions for all the folders on the levels above.

This will ensure that the user can access the folder to which he/she has received permissions.

With Excel and some knowledge of scripting, it is possible to construct a simple way to create and administrate these security groups with folder permissions.

Restriction of Folder Permissions and Assignment of Permissions to Permission Groups

After all the necessary security groups have been created within the Active Directory, it is necessary to give these groups permissions for all appropriate folders. One should start with the highest folder in the hierarchy. In our example, that would be the “Sales” folder.

The process of allocation of folder permissions is done in three steps:

i). In the first step, any existing inherited permissions must be deactivated or revoked.

This will ensure that the folder will only have explicitly assigned permissions. If you deactivate the permissions, you should also delete the associated user account(s) from the Active Directory so that the user(s) no longer enjoy access.

ii). In the second step, the permissions for the administrator group must be created. The following best practices are worth taking note of:

  1. The built-in account “system” receives “Full Control” permission. This is important since the operating system uses this account for certain services and processes. Thus, you should ensure that this permission is always granted.
  2. The local group “Administrators” will likewise receive “Full Control”. This ensures that the server administrators always have access to the necessary data and permissions. In addition, some backup programs also need these permissions to function correctly.
  3. Furthermore, you should create a security group for operators and administrators with “Full Control”. This guarantees that the IT administrators have the necessary permissions for the daily operation of the file server.

iii). In the third step, the security groups created for each folder must be assigned to the folder. The awarded permissions will be assigned as follows:

Awarding Additional Permissions for Deep Data Sub-Structures

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-07.png

You should avoid setting the level for managed folders to go very deeply within your folder structure. You can limit your folder structure to go not more than the fifth level.

If there are no restrictions on the number of levels in the file structure for the assignment of permissions, the complexity of the administration tasks increases exponentially. Suppose that the average number of subfolders in a file system is 10.

The complexity of the administration and documentation of the highest-level folder will be 10. If a second level is included, the complexity will increase to 10×10 or 100.

If we further assume that the average folder depth is 10 and that there are no restrictions on folder authorisations, the management complexity will be 10 billion.

That means an IT administrator may theoretically be required to manage 10 billion permissions. This further complicates documentation, reporting, and changes.

Avoid “Deny” Permissions

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-09.png

The need to deny a user access to a specific folder does not mean that you should use the “Deny” permission, as doing so increases the complexity of administration, documentation, and reporting by an unnecessarily large magnitude.

For example, during each assignment of permissions, all “deny” groups within the parent data areas must be checked.

When planning the folder structure, one must always keep this consideration in mind and structure the files with their permission groups in such a way that the “Deny” permission is not used at all.

In practice, this is easily possible if you present the users with a folder structure and do not capitulate to the requests of every staff member.

Do Not Use the “Share” Permission

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-10.png

When creating shares within a file system, it is possible to restrict access to the shares to which “Share” permissions have been given.

This unnecessarily doubles the complexity of administration. Instead, one should generally assign a “Write” permission.

Furthermore, to avoid unwanted attempts to gain access, one can hide the shares (by putting a $ sign at the end of the share name).

In Windows Server 2012, the “access-based enumeration” setting has the effect that a user will only be able to see a folder if he/she has a permission to see it.

Download Checklist

Click here to download a checklist that will assist you with using security groups for assigning permissions .


In the next step, we’ll talk about assigning users to active directory security groups.

Managing Data Access on Windows Fileservers: Processes and Responsibilities

Step 2: Processes and Responsibilities

Definition of Business Processes and Responsibilities

The second step in properly managing data access on Windows fileservers is to clearly define business processes and responsibilities.

Each user has a specific responsibility within the business premise. To carry out the various processes and realise the business’ goals, every user should be granted the privileges to access certain resources and undertake particular tasks.

However, allowing users uncensored access to system and network resources within the organisation can weaken its security and stability.

Importantly, access to computer or network access should be restricted based on the responsibilities of individual users within the organisation.

If a user is not responsible for a particular business process, there is no need of granting him or her permissions to perform the task.

Since controlling access to business data is the foundation of data security and, in some cases, of data privacy, universally applicable, mandatory processes must be defined together with someone from senior management.

The process of defining processes and responsibilities should be based on a comprehensive assessment of how a business operates, and should include input from the management.

The management must also be willing to give its full support to the implementation and enforcement of the role-based access control (RBAC) rules.


What are Business Processes?

Business processes define work flows and responsibilities. In addition, processes can also outline the tools required or recommended for the execution of said processes.

Some examples of processes:

  • Data requests
    • Requesting permissions
    • Changing permissions
    • Withdrawing permissions
  • Creating new objects
  • Assignment of and changes to responsibilities
  • Assignment and modification of owners
  • Expansion of storage requirements

Processes are often presented in the form of diagrams. Below, you will find a simple example of an assignment of permissions.


Compliance with these processes must be mandatory.

To ensure mandatory compliance, one must have the support of senior management or IT management, who must then communicate the necessary access control rules to all employees.

What are Responsibilities?

Responsibilities are defined based on the user’s competency, functions, and authority.

In an organisation, responsibilities can be created, changed, or discontinued depending on the prevailing needs and goals to be accomplished.

Responsibilities describe the types of processes that users are allowed to accomplish within the organisation.

Through assigning responsibilities to users, the management can ensure various processes are completed based on the intended goals to be achieved.

The IT department should work together with the management to ensure that users do not have access to resources beyond their stipulated responsibilities or level of control.

In case of changes in responsibility, the access level for that user should be adjusted as soon as possible. If a user has unnecessary access to a particular system, it can hamper the smooth running of the business process.

The following scenario illustrates how responsibility can be managed:

Irene works in the Marketing department and requires to view—but not create or modify—certain files from the Finance department. The Finance department, which is fully responsible for these files, utilises access control to restrict the users allowed to have Read-only, Write, or Modify access to them.

Irene is granted Read-only permissions to the Finance files. Likewise, the IT department resolves that preventing users such as Irene from creating changes to their systems can assist processes within the company run smoothly and enhance security.

Consequently, IT moves Irene and other users to the Users group, which restricts their actions to their assigned responsibilities and prevents them from making any reconfigurations to the system.

As a result, Irene has access to the resources she needs to undertake her responsibilities, the security of the processes within the organisation are improved, and stability of the network is solidified.

Responsibility of the Executive Board or Management

Administrators are responsible for the management of IT infrastructure, but they are not responsible for file structures or business processes concerning the assignment of permissions to data or other IT objects.


Often there will be few or no documented IT processes, which indicates that documentation is not being done well enough.

Unfortunately, senior management will often place the responsibility for permissions in the hands of the IT administrator.

This is not a good idea. For instance, decisions regarding whether an employee shall have access to sales data will time and again prove to be poor decisions, especially if the “applicant” has better argumentation skills than the IT staff member or is located in another level of the company hierarchy.

In other words, if the head of the “service” department wants his employees to receive permission to access data in the “sales” department, the decision should only be made by the head of the “sales” department.

Managing Changes in Responsibilities

The responsibilities of users should be aligned with their data access privileges. In case of changes in responsibilities, the previously allowed rights should be revoked and proper adjustments made.

For example, giving new staff members with new responsibilities a handbook that describes the IT environment of the company and all of the company’s IT processes has been proved to be extremely beneficial in managing changes in organisations.

If a new employee requests for access rights, the data access privileges should only be awarded when the mandatory approval process has been successfully carried out – without exception.


To demonstrate the execution of the individual steps in a process, it is necessary to have so-called “Use Cases”. Use Cases are step-by-step explanations of how an administrator (for example) creates a new file folder with individual permissions, especially when users change roles in an organisation.

Further examples are:

  • Awarding a new user permission to access a particular data area
  • Revocation of an old user’s permission to access a particular data area


Lack of Compliance with Business Processes and Requirements

Employees will frequently attempt to circumvent business processes. A typical example of this would be a call to the IT department, without filling out the required permission forms, to gain certain permissions.

This will typically be justified by arguments like “it’s important”, “it’s urgent”, “I forgot to fill out the forms, but the new staff member is already here”, “I have specific instructions from the boss”, “if I don’t get the permissions immediately, then….”

In such cases, the IT staff member will normally fail to document the assignment of permissions.

The reason that there was “not enough time” will often be used to circumvent clear instructions regarding file folder structures or permission concepts.

The following scenario is a good illustration of this:

There is a requirement that access permissions for a file server may only be given on the file folder level. Despite this, the department head makes a request to receive the necessary permissions to access a specific file.

To resolve this conflict, the IT administrator will have to create a new file folder and put the file into it. It would then be necessary to create and assign all permissions for this file folder.

Instead of doing that, IT administrators will frequently try to save time and give the department head the requisite permissions for the file as a “one-off” exception.

Best Practices

Here are some practices you should follow to ensure proper management of processes and responsibilities:

  • Implement the principle of least privilege, where users are granted the minimum access rights to carry out their responsibilities. This assists to ensure that if a user’s account is hacked, the consequences to the business processes are minimized by the limited rights the user possesses.
  • Periodically audit the responsibilities within the organisation to ensure they are aligned with the stipulated processes. If not, revoke the unnecessary permissions and make proper adjustments.
  • Do not give in to the temptation of creating exceptions for circumventing the already assigned responsibilities and rules. If you do this, you will be avoiding complying with business processes and requirements, and endangering the security of the organisation.
  • Recognise that not every employee requires a starring role, and properly grant access rights based on the stipulated responsibilities, and nothing more.
  • Ensure that the IT department works together with the senior management so that employees’ access privileges are properly aligned with their responsibilities within the organisation.

Download Checklist

Click here to download a checklist that will assist you with defining business processes and responsibilities.


In the next step, we’ll talk about using security groups for assigning permissions.

Managing Data Access on Windows Fileservers: Planning

 Step 1: Planning

Designing Folder Structure and Policies for Permission Assignment

Foremost, to successfully manage data access on Windows fileservers, sufficient planning is necessary—or failure could ensue.

Comprehensively planning the designing of folder structures and policies for permission assignment will greatly minimise administrative headaches and maximise productivity.

Planning how to set up folder structure for deployment to your team is indispensable. In the absence of planning, all your efforts to manage data access may fail to yield the desired results.

Incorporating some planning can transform your shared-folder environment into the land flowing with milk and honey.

To successfully and efficiently operate a complex Windows Folder Structure without any hassles or security leaks, you have to take the following points into consideration:

  • Plan a folder structure to store the users’ data files (documents, slides, graphics, drawings, etc.)
  • Plan the shares
  • Plan the Active Directory security groups
  • Plan the permissions


Why is Planning the Design of Folder Structure Important?

If there is a lack of definition for any of the above topics or if substantial mistakes are made in the planning phase, the problems that occur during operation will increase with each day.

Thus, you will require more time for operations, analysing problems will become more difficult, and the necessary enhancements will require far more effort to archive.

Most of the time, the only solution will be to plan and create a completely new Windows filesystem environment, which will include a time-intensive data migration into the new folder structure.

The first step is to setup a folder structure and assign the appropriate permissions to that structure. The next step is the long-term daily management and operation of that environment.

Below are some of the real-life situations that a Windows administrator could have a hard time dealing with if a proper folder structure is not designed from the start:

  • The project manager urgently needs a new folder added to the project share with permissions set for only the project office.
  • The employees in the accounting department change so often that, every day, a new employee needs to have permission assignments while exiting teammates need their permissions removed.
  • The boss of the legal department has doubts that his data is secure and requests a list of the data trustees for his folders.

Huge mistakes will make the administrator’s job far more stressful and will force them to do many routine operations and tedious tasks. Such wasted time can be invested in much more useful technologies.

What’s the importance of planning for authorisation concept?

A solid, comprehensive plan will help avoid problems! The key to a secure and stable Windows Share and Folder environment is a solid authorisation concept. If this is in place, you can trust in the security of your data!

It is important to plan for an access authorisation concept before your IT administrators create new data structures within your system, no matter if those structures are for file data, web pages (Microsoft SharePoint), databases (MS SQL Server), applications, mailing lists, or folders (Microsoft Exchange).


If this authorisation concept is missing on all levels, especially for:

a) use cases, such as:

  • Permission assignments for users
  • Withdrawal of permissions for individual users in individual access areas
  • Simple reporting of access rights

b) and business processes, such as:

  • Approval processes for data access
  • Approval processes for the creation of new objects in the data structure

then, the tasks of day-to-day management and medium-term reporting will no longer be easily implementable.

These tasks will grow increasingly time-intensive as more uncertainties and security risks manifest.

This is a nightmare for every IT administrator and security officer. Therefore, proper planning beforehand is essential.

Creation of a Windows Folder Structure

What kind of plan should you have for smooth daily operations?

The needs of your organisation will likely determine the way you plan for the creation of a Windows folder structure.

If you have a plan that allows for a folder structure that is intuitive and easy to navigate, it will greatly smooth daily operations and maximise productivity.

You should ensure that poor practices and inefficient workflows are not included in your planning.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-03.png

Here are some questions to consider when planning your structures:

  • How should data files get organised? Are users allowed to create folders on their own?
  • Who is responsible for moving, owning, and maintaining the data? Whom do I speak to if an employee from one department requests permissions for a folder in a different department?
  • How should the shares be designed? For instance, does every department need its own share? Is one share per business domain enough?
  • How should the structure for the folders in the Active Directory be built? How should the Active Directory security groups be designed?
  • How should I name the shares, folders, and Active Directory security groups?
  • Should folder depth be limited? Is it efficient to manage the permissions of folders five levels deep?
  • How should users who are assigned to specific folders gain access? Why shouldn’t users be directly assigned to those folders? Do users need different levels of access or are groups suitable?
  • How should the files and folders be backed up? How do I guarantee the software will be able to access all the data within the structure?
  • Are there any specific security concerns around your shared content?

Do your administrators require full access to users’ content?

To answer these questions, you’ll need to define some policies for permissions assignment:

  • Policies for file and folder structures
  • Policies for every data owner; that is, who is responsible for which folder
  • Policies for shares
  • Policies for security groups in the Active Directory
  • Policies for naming conventions for shares, folders, and groups
  • Policies for folder nesting depth limits
  • Policies for permission assignments of users to gain access
  • Policies for permission assignments for backup service accounts, operators, and administrators

Some Suggestions

Here are some real-life examples of defined policies:

  • Shares: The amount of shares is not limited.
  • Shares: The names should not be longer than 10 characters. Special characters are not allowed.
  • Folders: The amount of folders is not limited.
  • Folders with Permissions: The name of a folder should not exceed 15 characters. Special characters (_ and ,) are not allowed.
  • Permissions: Permissions are assigned to folders, never to shares or files. Only permissions of type “Allow” are allowed. Never assign permissions of type “Deny”.
  • Folder Nesting: Only assign security groups permissions to folders in the first or second hierarchy level. Child folders do inherit the permissions of their parent folders.


  • Security Groups: For every folder with necessary permissions, an appropriate security group is created in the Active Directory.
  • Naming Convention: Name security groups like this: FS_<sharename>_<foldername>[_<foldername>]_<permissions>
  • Quota: Every folder with permissions will get a default quota of 100 GB. Enhancements should be requested by the data owner.
  • Responsibility: For every folder with permissions, a responsible individual must be defined to manage said permissions. This person will decide who gets which kind of access permissions or quota enhancements.


When your IT team takes all these policies and rules into consideration, you will be able to avoid most of the problems mentioned earlier.

Best Practices

Here are some practices you should follow to ensure quality planning when setting up your structures:

  • Define your policies and rules in detail. This step will help you ensure simple administration and smooth daily operations.
  • Exceptions must always be documented.
  • Never assign permissions to shares. Only assign permissions to the underlying folders!
  • Never assign full control to shares or folders. This could lead to administrators accidentally being locked out by users.
  • Remove “creator” and “owner” permissions. Having such permissions could lead to lock outs.
  • Only assign full control to the folders within the internal system account.
  • Plan for your sensitive, confidential data to live towards the top of your structure (at a higher folder level). This way, you can easily restrict unauthorised access.
  • To enhance efficiency, ensure the folder structure is as flat as possible. A quick rule of thumb is to set the limit for managed folders to go as far as the third level within your structure. Beyond this level, if users create more folders based on their needs, those folders will not have any permissions assigned to them.
  • The IT department should never be the data owners. Any data owners must be an employee of an appropriate department.
  • Observe clear, consistent naming conventions for folders. This way, a user can easily search for content without losing focus.
  • For external collaboration, create separate and clearly labeled folders. For example, you can create a separate root level folder for communicating with third parties.
  • Plan to actively police permissions by frequently cleaning out unnecessary and un-audited permissions.

Download Checklist

Click here to download a checklist that will assist you with planning on how to manage data access on Windows fileservers effectively.


In the next step, we’ll talk about defining business processes and responsibilities.

Managing Data Access on Windows Fileservers: Introduction

Windows fileservers are usually seen as convenient storage systems for managing data access within an organisation.

However, fileservers are a mixed blessing: aside from being effective in providing easy user access, their improper management is often the headache of the IT department.

Unauthorised access to shared data, distortion and even deletion and alteration of files and folders, as well as illicit exfiltration of sensitive data are some of the pains that fileservers cause to most small and large organisations.

Importance of  managing data access on Windows fileservers

Here are five reasons why properly managing data access on Windows fileservers is important.

1. Prevent Privilege Creep

Privilege creep is a security nuisance that occurs when a user gathers excessive access rights than initially intended.

If a user’s access privileges are not revoked, particularly after changing roles within the organisation, it can result into a privilege creep.

For example, if a manager with access rights to important company files is demoted, and the rights are not revoked, he may misuse the privileges and cause major damages.

Why is preventing privilege creep important?

  • An employee with unrevoked privileges can maliciously access important data and bring the company to its knees
  • If an account of an employee with uncleaned privileges is hacked, it can lead to more excessive damages
  • Managing user accounts with excessive privileges is burdensome and costly

2. Prevent Data Breaches

If access to Windows fileservers is not properly managed and unauthorized access prevented, it can result into heavy data loss and theft.

Data breaches are a nightmare to organisations worldwide, with a recent study estimating that they led to losses of about $3,62 million in 2017.

Currently, most organisations have invested in heavy IT infrastructure where a huge number of files and folders are accessed frequently.

In such a scenario, tracking unauthorised access whenever there is inappropriate access to sensitive files and folders becomes difficult, unless there is considerable investment in managing access.

If security logs are regularly examined, network is regularly scanned, and outbound traffic is regularly monitored, it can substantially reduce the potential risks of data breaches.

3. Better Auditing of Sensitive Folders and Files

Properly managing data access on Windows fileservers assists in better auditing and tracking on the usage of sensitive folders and files.

If permissions are granted to users, the actions they undertake, such as file creation or modification, can be tracked.


With proper management, it is easier to get answers to “Who”, “What”, “When”, and “Where” questions concerning any alterations made by any user in Windows fileservers within the network.

This way, if the auditing reveals wrong usage, the permissions can be revoked to ensure security is maintained.

The following example is an illustration of this:

A user group can be granted permissions to “List folder contents”. This permission allows the group to view and list the items present in the selected folder.

However, if the auditing reveals that the user group also has other unintended permissions, they can be revoked and reassigned.

4. Provide complete visibility of fileservers

Practicing proper management provides comprehensive information on every access event taking place across the Windows fileservers.

With complete visibility of every user activity across the organisation’s fileservers, improper settings and security loopholes can be prevented.


The following example is an illustration of this:

If a visibility analysis reveals that “Deny” permissions have been assigned to a folder, it implies that Allow permissions will be overridden, leading to insecure administrative hurdles that are difficult to solve.

Therefore, with complete visibility of the fileservers, such improper settings can be avoided.

5. Saves Time and Efforts

Properly managing data access on Windows fileservers also lessens the wastage of time and energy associated with various fileserver activities.

The following example is an illustration of this:

If a security group is nested it can lead to wastage of time and efforts in keeping track of the various fileserver activities.

In case a group belongs to another group, whose members can access a particular folder, any analysis will be time-consuming and prone to security flaws.

C:\Users\carst\AppData\Local\Microsoft\Windows\INetCache\Content.Word\separated index02-03.png

However, with proper management, considerable amount of time can be saved in ensuring the best practices are observed for optimal network security.


In the next couple of articles, we’ll talk about the five steps to managing data access on Windows fileservers effectively.

Here are the steps we’ll cover: