How to Audit NTFS Folder Permissions Before Your Next Compliance Review

An NTFS permissions audit examines every access control entry on every folder in a directory tree, identifies who has access to what, separates inherited from explicit permissions, and flags entries that violate least-privilege principles — producing a documented evidence pack that answers the questions compliance auditors ask.

If your organization is preparing for a SOC2, HIPAA, ISO 27001, or PCI audit, the auditor will ask about file access controls. The question takes different forms — "How do you ensure least-privilege access?" "Who can access sensitive data?" "How do you review file permissions?" — but the answer they want is always the same: documentation.

Not "we check it manually." Not "we have a PowerShell script." Documentation. A timestamped report showing every permission on every relevant folder, produced by a repeatable process.

---

What auditors actually ask about file permissions

The specific audit requirements vary by framework, but the core questions are consistent:

SOC2 (CC6.1 — Logical and Physical Access Controls): "The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events." Translation: who has access to what, and how do you know it's appropriate?

HIPAA (§164.312(a)(1) — Access Control): "Implement technical policies and procedures for electronic information systems that maintain ePHI to allow access only to those persons or software programs that have been granted access rights." Translation: can you prove that only authorized people access patient data?

ISO 27001 (A.9.2 — User Access Management): "To ensure authorized user access and to prevent unauthorized access to systems and services." Translation: show me your access review process and its output.

PCI DSS (Requirement 7): "Restrict access to cardholder data by business need to know." Translation: prove that the permissions on your cardholder data match the documented need-to-know policy.

Every framework asks the same underlying question: Can you prove that file access permissions match your documented access policy?

The proof is a permissions report. Not a screenshot of one folder's Security tab. A comprehensive report covering every relevant folder, showing every principal with access and what level of access they have.

---

Why most organizations fail this question

The honest answer in most SMBs: nobody reviews file permissions systematically. Access is granted when someone requests it. Access is rarely removed when someone changes roles or leaves. Over years, the permission structure drifts until it no longer resembles any documented policy — if a documented policy ever existed.

When audit time comes, the IT team scrambles. Someone opens a few folders in Windows Explorer, checks the Security tab, and takes screenshots. The screenshots show a handful of folders out of thousands, with no context about whether the permissions shown are appropriate.

The auditor sees partial evidence produced under time pressure. That's a finding — not because the permissions are necessarily wrong, but because the organization can't demonstrate a systematic review process.

---

The three components of an audit-ready permissions review

1. Complete enumeration

Every folder in the scope of the audit needs its permissions documented. For a SOC2 audit covering a file server with customer data, that might be the entire \\fileserver\CustomerData\ share tree. For HIPAA, it's wherever ePHI resides. For PCI, it's wherever cardholder data is stored.

"Complete" means every subfolder at every level — not a sample, not the top-level folders only. Permissions can vary at any depth, and auditors know that. A child folder with broken inheritance and Everyone:FullControl is exactly the kind of finding they're looking for.

2. Risk analysis — not just raw data

A list of every permission on every folder is useful but overwhelming. A file server with 5,000 folders and an average of 8 ACL entries per folder produces 40,000 rows. Nobody is going to review 40,000 rows looking for problems.

What makes a permissions audit actionable is risk analysis: filtering the 40,000 entries down to the 50-200 that represent actual risk. Everyone with Write access, broken inheritance, orphaned SIDs, service accounts with FullControl on user data paths — these are the findings that matter, and they need to be called out explicitly rather than hidden in a data dump.

3. Structured output that survives the audit

The output needs to be:

• Timestamped — when was this scan performed?
• Reproducible — the same tool run on the same path produces the same output
• Structured — CSV that can be sorted, filtered, and reviewed in Excel
• Separated — full inventory in one file, risk findings in another. The auditor gets the risk report. The full inventory is available if they want to dig deeper.
• Archivable — files that can be stored with the audit evidence and referenced months or years later

A folder of files on the auditor's desk or in the compliance evidence repository is infinitely more useful than a memory of "we checked it and it looked fine."

---

The quarterly review cadence

Compliance frameworks don't ask for a one-time permissions audit. They ask for evidence of an ongoing review process. SOC2 explicitly requires periodic access reviews. HIPAA requires regular review of access controls. ISO 27001 requires access rights to be reviewed at defined intervals.

The practical implementation: quarterly permissions audits.

• Q1: Baseline scan. Document the current state. Flag and remediate any critical or high-risk findings.
• Q2: Delta scan. Compare against Q1. Identify what changed. Investigate any new risk findings. Document remediations.
• Q3: Same as Q2. The pattern is established. New findings should be rare if remediation is working.
• Q4: Year-end scan. Comprehensive review. Package all four quarterly scans as evidence for the annual audit.

Each quarterly scan takes minutes to run and produces an evidence pack that goes into the compliance file. Over four quarters, you build a documented history of permission reviews that auditors love — it shows not just the current state but the trajectory.

---

What a permissions audit reveals in practice

On a file server that's been in production for 3+ years without systematic permission reviews, the first audit typically finds:

Everyone or Authenticated Users with Write access on shared folders. This is more common than anyone expects. Someone created a folder, set permissions to Everyone:FullControl to "get it working," and never restricted it. Three years later, it's still wide open.

Orphaned SIDs from departed employees. Every employee who left the company and had explicit permissions on any folder is now an unresolved SID in the ACL. These entries do nothing useful but clutter reports and occasionally cause access evaluation delays.

Broken inheritance on subfolders with no documentation. Someone broke inheritance to restrict a subfolder and then the context was lost. The subfolder now has permissions that don't match the parent or any documented standard.

Service accounts with unnecessary FullControl. A backup agent, an antivirus scanner, or a monitoring tool was given FullControl on a data path when it only needed Read access. The application works, but the service account is a privileged access path that nobody monitors.

Permission depth exceeding rational limits. Five or six levels of nested explicit overrides indicate a permission structure that has been patched repeatedly rather than designed. Usually the result of multiple admins making "quick fixes" over time without understanding the full inheritance chain.

None of these findings are necessarily catastrophic on their own. But each one is a compliance finding, and collectively they represent a permission structure that nobody controls.

---

What to do next

If your next compliance review is approaching and you can't produce a documented permissions audit for your file servers, you have a gap that needs closing before the auditor arrives. The time to fix it is now — not the week of the audit.

NTFS Permissions Auditor walks the directory tree, reports every ACL entry with inherited-vs-explicit separation, applies risk scoring, and produces a timestamped evidence pack — summary, full permissions CSV, risk findings CSV, and machine-readable JSON. The trial scans 500 paths — enough to see the output and risk scoring on a real file share.

Run the first scan now. Remediate the critical findings. Run the second scan next quarter. By the time the auditor arrives, you have a documented review process with evidence.