Safeguard 3.3 Configure data access control lists: evidence

What Safeguard 3.3 data access control lists require and why they are hard

Safeguard 3.3 asks you to configure access permissions on data so that each user can reach only the data they need to do their job, and to apply those permissions wherever the data lives: in databases, in applications and on file systems, whether local or remote. It sits at the data layer. Controls 5 and 6 decide which accounts exist and what roles or groups a person holds, while Safeguard 3.3 decides which rows, tables, folders, files, shares and application objects those identities can actually read, change, or delete. An auditor will expect to see both layers, and a clean account review does not prove the data layer is correct. In CIS Controls v8.1, the Safeguard belongs to the Data asset class and the Protect security function, and it is assigned to all three Implementation Groups, so it is part of the IG1 essential cyber hygiene baseline that every enterprise is expected to meet.

The difficulty is drift. Permissions on a file share are usually granted by folder and group, on a database by schema, role or grant, and in a business application by a separate role model that its vendor or internal team maintained. Each system accumulates exceptions for projects, temporary cover and one-off requests, and nobody is assigned to remove them when the need ends. Because the three layers are administered separately, no single screen shows whether a user's effective access still matches their need to know. Before you measure anything, confirm with the data owners which systems hold sensitive data, which of them enforce access at the data level, and who approves changes. The data inventory under Safeguard 3.2 and the account inventory under Safeguard 5.1 are the inputs the assessment specification expects you to have first.

The practical decision is how far the data-level model will be centralized. Some platforms can enforce rules per folder, per file attribute or per request context, while others only offer coarse permissions, so you need to know your tooling's limits before writing a standard. Open-source options can help you enforce and review these rules. For example, Nextcloud's File Access Control app can deny upload, download, sync and other operations based on rules that match user group, IP address, file name or MIME type, which is an enforcement point for file-level need to know. Certification campaigns in midPoint, where designated reviewers keep, change or revoke access items within a set timeframe, can counter access accumulation across systems. Confirm each feature against the version you run, since capabilities differ by release and deployment, and check the CIS Controls Assessment Specification for Safeguard 3.3 for what the measures require.

Which data stores and teams fall under data access control lists

Safeguard 3.3 applies wherever sensitive data lives, which is wider than the core database. The cards below walk through the stores, the people who decide permissions and the scoping choices that determine what the Safeguard covers. Each choice feeds the others, so the scope should be agreed once and documented.

Databases and data warehouses

Production databases, reporting replicas and analytics warehouses are the most common places where row, table and column permissions are set. Check whether each engine has its own grant model and whether application service accounts hold broader rights than the people behind them. Confirm that test and backup copies inherit the same restrictions as production.

Applications and business systems

Line-of-business applications often hold data permissions inside their own role or record-level rules, separate from the database beneath them. Document which application roles can view, export or change sensitive records. Include reporting tools and integrations that read the same records, since they widen access without appearing in the application's admin screens.

File shares and collaboration platforms

Local and remote file systems, network shares and self-hosted collaboration suites hold unstructured sensitive data that is easy to over-share. Nextcloud's File Access Control app, for example, can deny upload, download or sync based on group, IP address or file type. Confirm which shares sit outside the inventory and which folders inherit broad group permissions.

SaaS data stores and service providers

Copies of sensitive data held by SaaS products and external processors fall under the same need-to-know principle, even when the organization does not run the system. Ask each provider which of its own staff can reach your data and how those permissions are reviewed. Record these stores in the data inventory so the access review reaches them.

Data owners and business sponsors

The data owner decides who should have access to a dataset and at what level, based on business need. Owners should approve access requests and confirm that the permissions still match the role. Name one accountable owner per sensitive data class, since a shared owner usually means no one reviews the list.

Administrators who implement permissions

Database, application and file administrators translate owner decisions into access control lists and keep them configured. They need documented change records so each permission can be traced to an approval. Their own elevated rights should sit under Safeguards 5.4 and 6.8, which govern administrator accounts and role-based access.

How an assessor tests data access control lists

This table maps the parts of the CIS Assessment Specification approach for Safeguard 3.3 to what the assessor checks, the evidence requested and where implementations usually fall short. Read it as a preparation checklist: each row shows what must be ready before the assessor arrives.

Assessment element	What the assessor checks	Evidence usually requested	Common finding
Eight measures, two metrics	The eight measures in the CIS Assessment Specification roll up into a metric on completeness of user access control and a metric on properly configured assets	Measure-by-measure results showing which data stores and users were covered	Results reported as a single pass without per-store detail
Prerequisite: Safeguard 3.2	Whether a data inventory exists that lists the data stores the access control measurement must cover	Current data inventory with owners and locations for each store	Inventory omits file shares, SaaS exports or database replicas
Prerequisite: Safeguard 4.1	Whether a secure configuration process governs how access settings on data assets are set and checked	Documented configuration process and records of configuration changes	Permissions changed directly on systems with no recorded baseline
Prerequisite: Safeguard 5.1	Whether the account inventory shows every user, service account and group that can reach the data	Account inventory exported from directory or identity systems	Service accounts with data access are missing from the inventory
Sampling of data stores	Whether a representative set of databases, applications and file systems is selected and checked against the documented access rules	Sample list with the access control list for each store and the rule that applies to it	Sample limited to the stores the team already manages well
Sampling of users	Whether the access granted to sampled users matches their documented need to know for their role	Role descriptions, access requests and approvals for the sampled users	Access granted to a role but never checked against the actual job function
Inherited broad group permissions	Whether group membership grants access wider than any single user needs	Effective permission reports showing inherited access, not only direct grants	Large groups such as all staff granted read access to sensitive folders
Unreviewed ownership	Whether each data store has a named owner who approves and reviews its access list	Ownership register and dated records of owner review	Stores with no owner, or owners who never approved current access
Local and remote access	Whether access rules apply the same way to local file systems, remote shares and cloud-hosted applications	Configuration exports from each store type, including remote and hosted systems	Remote or cloud stores set up outside the standard access process

Sequence to configure data access control lists

This sequence turns Safeguard 3.3 into a working data-level access layer: it starts from the inventories that tell you what data and accounts exist, sets need-to-know rules with named owners, applies them in each store, proves the effective permissions match the rules, and keeps them current through review.

Confirm the data and account inventories
Before writing any rule, confirm that the data inventory from Safeguard 3.2 and the account inventory from Safeguard 5.1 are current. The CIS Controls Assessment Specification lists both as prerequisites for measuring Safeguard 3.3, so gaps here will carry into every later step. Data owners, IT administrators and the security lead review the inventories together and record which data stores, applications and file shares are missing or out of date. The output is a signed-off list of in-scope data stores and the accounts that can reach them, with known gaps logged for remediation.
Define need-to-know rules per data class
Group the inventoried data into classes based on the sensitivity levels set in the data management process under Safeguard 3.1, then write the access rule for each class: which roles or groups may read, change, create or delete it, and under what conditions. Each class needs a named data owner who approves the rule, because owners decide need to know and IT administrators do not. The output is a per-class access rule register showing the owner, the permitted roles and the justification for each grant.
Apply the rules in each data store
Translate the approved rules into the native access controls of each store: database grants and roles, application permissions, and file system access control lists, whether the store is local or remote. Where a platform supports a rule layer on top of file or sharing access, such as the File Access Control app in Nextcloud (AGPL-3.0-only), configure it to match the register and confirm the platform's exact capabilities against its own documentation before relying on them. Configuration changes should go through your standard change process and be captured in version control or configuration records. The output is a configuration baseline per store that maps directly to the register.
Validate effective permissions against the rules
Test what users can actually do, not what the configuration intends. Sample accounts from each role, attempt reads, writes and deletes against representative data in each store, and compare results to the register. Check inherited permissions, group nesting and service accounts, since these often grant access the register never mentions. Record every mismatch, fix it, and retest. The output is a validation record listing the tests run, the expected result, the observed result and the closure of each exception, which is the evidence an assessor will ask to see.
Review access on a recurring schedule
Set a review cadence for each data class, with the data owner confirming that every grant is still needed. Access accumulates over time as people change roles, so reviews should also check for grants that no longer match the register. Access certification campaigns, such as those in midPoint (EUPL-1.2+), show one pattern: designated reviewers decide within a set timeframe whether to keep, change or revoke each access item. Agree the review frequency with your auditor or assessor, since the Safeguard text does not fix a number. The output is a signed review record per data class and a log of revocations and rule changes.
Feed review findings back into the inventories
Close the loop by updating the data inventory and the account inventory with what the review found. New data stores, retired applications and orphaned accounts change the scope of the access rules, so the rules and the inventories must be refreshed together. Confirm that the register version, the validation record and the review record all reference the same inventory version. The output is an updated inventory set and a change record that shows the next review starts from current scope.

How access accumulation undermines the control over time

A data access control list that was correct on the day it was configured can be wrong six months later, and nothing in the configuration will say so. Permissions accumulate. When someone moves from a finance analyst role to a reporting role, the new grants are usually added while the old ones stay in place, because removing them is nobody's explicit task. Group membership makes this worse. A user added to a group for a one-off project may inherit read access to a sensitive database schema that the group was never meant to reach for everyone in it, and the ACL on the database still looks tidy because the grant sits one level away, on the group.

This is why a one-time configuration passes a snapshot test and fails a later review. An assessor who checks the ACLs on a given day against a list of approved users may find every entry justified, yet miss the access that has piled up through role changes, nested groups and temporary exceptions that were never revoked. The control only holds if someone periodically asks whether each permission is still needed for the work the person does today. Ask your team which group memberships grant data access, and which owner signs off on each one, before you treat the configuration as finished.

Periodic access certification is the usual counter. In midPoint, an access certification campaign assigns designated reviewers who decide, within a set timeframe, whether to keep, change or revoke each access item, such as a role assignment. The campaign produces a dated record of those decisions, which is the kind of evidence an assessor can sample. Confirm with your own identity team how often reviews must run, who the reviewers are for data-level permissions as distinct from application logins, and what happens to items that receive no decision in time. Those answers belong in your data management process and access procedures, not only in the tool settings.

Evidence that shows data access control lists are working

An assessor testing Safeguard 3.3 looks for proof that permissions on data stores were designed from owner decisions, configured as approved, and kept that way over time. The cards below cover the artifacts that carry that chain of evidence, and how to refresh each one between assessments so it reflects the environment as it is today.

Data-store permission exports

Exports of the effective permission settings on each database, application and file system in scope, taken from the systems themselves rather than from documentation. Include the store name, the principals or groups granted access, the permission level and the export timestamp. Check that every store listed in the data inventory under Safeguard 3.2 appears in the exports, since an unlisted store is an unmeasured one. Schedule the exports to run automatically and retain each dated snapshot so changes between runs can be traced.

Owner-approved access matrices

A matrix that maps each data set to the roles or groups allowed to read, change or delete it, signed off by the named data owner. The matrix is the reference point that every other artifact is compared against, so it should state the need-to-know basis for each grant. Review it when data owners change, when a new data set is classified and at least once a year. Record the approver and approval date on the matrix itself.

Configuration baselines from Safeguard 4.1

Hardened configuration baselines for the databases, applications and file servers that enforce the access rules, produced under the secure configuration process in Safeguard 4.1. Keep the baseline version, the change history and the scan results that show each system matches it. A baseline that permits anonymous access or broad group inheritance on a sensitive store is a finding even when the matrix is correct, so review the baseline against the matrix together.

Access review records with decisions

Records from periodic reviews in which a designated reviewer decides whether each data access item is kept, changed or revoked, with the reviewer name, decision and date. Open-source identity governance tools such as midPoint support certification campaigns with a set decision timeframe, which makes the record easier to produce on request. Confirm that revoked items were actually removed from the store, because a recorded revocation that was never applied is a common assessor finding.

Change tickets for permission updates

Tickets that authorize every change to a data access control list, showing the requester, the data owner approval, the implementation and the person who verified it. Each ticket should reference the matrix entry it changes. Ask whether emergency changes are allowed and, if so, whether they are reviewed after the fact. Tickets without a matching entry in the permission export taken afterward point to changes made outside the process.

Effective permission samples against the matrix

Sampled checks in which a tester attempts to read, change or delete selected data as test accounts in each role, and compares the observed results with what the approved matrix allows. Sampling should cover each store type in scope and include negative tests for roles that must be denied. For each sample, retain the test account, the action, the result and the matrix line it tests. Where a sample disagrees with the matrix, log the gap as a finding with an owner and a due date.

What meeting Safeguard 3.3 costs in money and effort

This table breaks down the cost components of configuring data access control lists under Safeguard 3.3, who is paid for each one, and whether it is one-time or recurring. Use it to scope a quote, since most of the cost scales with the number of data stores and identity sources rather than with licenses.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Mapping need to know per data set	Data owners, business leads and internal engineers agreeing who should see what	One-time, then recurring when roles change	Number of data sets and how many business owners must sign off
Configuring access control lists per store	Internal platform engineers or an implementation partner, per database, application and file system	One-time per store, plus changes	Count of stores, local versus remote hosting and how many use native permission models
Identity source integration	Engineers linking directory or identity systems to each data store	One-time, with ongoing maintenance	Number of identity sources and whether group membership is already clean
Access review cycles	Designated reviewers keep, change or revoke access items within a set timeframe	Recurring	Frequency set in your data management process, number of reviewers and access items per review
Tooling and licenses	Software vendors or none if self-hosted open-source tools are used	Recurring if commercial, often low or none with open source	Choice of access certification and file access control tools, and whether support is bought
Evidence upkeep	Internal compliance or security staff exporting permission reports and review records	Recurring	Automation of exports, change tickets and how current the data inventory is
Assessor sampling and walkthroughs	Internal staff supporting the independent assessor, and the assessor's fees	Recurring at each assessment cycle	Number of stores in scope, quality of documentation and sample sizes the assessor selects
Partner support, if used	Implementation partner under a fixed written scope	Usually one-time build, with optional recurring retainer	Clarity of scope, number of stores, and whether upgrades and testing are included

Who owns, implements and assesses this safeguard

The organization owns Safeguard 3.3. Data owners decide who needs which data and why, IT operations keeps the stores and file systems that hold the data, and the security team sets the standard the lists must meet and checks exceptions. Those decisions cannot be delegated to an outside party, because the access rules must reflect the organization's own business need to know.

Data owners: name the datasets they are accountable for and approve who may read, change or export them.
IT operations: maintain the database roles, file share permissions and application groups that carry those approvals.
Security team: defines the review cycle, the exception process and the minimum standard for each sensitivity level.
HR and managers: report role changes and departures so access lists are updated promptly.

Confirm with your own assessor which owner signs off on access lists and how often they must do so, because the evidence needs to name those people.

Where data access control lists usually fall short

Data access control lists tend to fail in the same few places: nobody owns the data, permissions drift toward broad groups, and the copies that live outside the main systems never get reviewed. Each card below names one gap that assessors look for under Safeguard 3.3 and the action that closes it.

No named data owners

Permissions on a dataset are only as defensible as the person who approves them. When no owner is recorded, access requests are decided by whoever happens to administer the system, and nobody can say whether a grant matches the documented need to know. Assessors measuring this Safeguard look for an owner recorded against each data set in the data inventory from Safeguard 3.2. Action: assign a named owner to every sensitive data set and record the owner beside its access list.

Permissions granted to broad groups

Groups such as all staff, domain users or every developer often sit on folders and tables because they were the fastest way to unblock someone. Each broad grant gives far more access than any single role needs, and the gap is easy to miss because the list looks tidy. Check which groups hold read or write rights on sensitive data and whether each group's membership matches a documented need. Action: replace broad group grants with narrow role-based groups and remove the broad grant once the narrow group works.

Unmanaged local file system shares

Shares created on individual servers or workstations often bypass the central directory and the review process. They may carry permissions copied from a parent folder years earlier, or grant access to local accounts that no longer exist in the identity system. Sweep file servers and endpoints for shares that hold sensitive data and confirm each one appears in the data inventory with an owner and an access list. Action: enumerate local and network shares, then bring each sensitive share under the same owner and review cycle as central storage.

Database roles never mapped to need to know

Database roles are often created by a project team, granted broadly for testing, and never reconciled with the business need behind them. Application service accounts may hold rights far beyond the queries they run, and shared administrative roles blur who accessed what. Compare each role's table and column privileges against the documented data use, paying attention to service accounts and reporting roles. Action: map every database role to a documented need, remove privileges that no use case requires, and separate reporting roles from write roles.

Missing review records

An access list that is correct on the day it was set can drift within months as people change teams and projects end. Without a dated record of who reviewed the list, what they decided and what changed, an assessor cannot confirm the permissions still follow need to know. Keep review evidence such as signed approvals, change tickets or certification campaign results. Action: schedule recurring reviews for each sensitive data set and keep the decision record with the access list.

Unverified remote access paths

Data can be reached through VPN gateways, remote desktop, web applications, file sync clients and API tokens, and each path may apply its own permission logic. A list that looks correct at the storage layer can be bypassed through an application that uses a different service account. Test each remote path against the same rules and confirm that the path enforces the list rather than assuming it does. Action: document every access path to each sensitive data set and verify, with test accounts, that each path returns only the permitted data.

Questions about data access control lists and Safeguard 3.3

What does Safeguard 3.3 data access control list work cost?

Cost depends on how many data stores need access rules, how many roles and groups exist today, and how much of the access model must be designed from scratch. No researched figure for this work is available, so ask for a fixed-scope quote built from a written list of systems. The main cost components are the time to map who needs what, the time to configure rules in each database, application and file system, and the time to produce evidence for an assessor. Costs recur when access reviews, rule changes and new data stores are added. Ask any provider to split one-time design and configuration from ongoing review support.

How long does it take to configure data access control lists?

The duration depends on the number of systems in scope, the state of existing permissions and how many owners must approve the access model. Without a researched duration, treat any timeline as provisional until the systems and owners are listed. Expect the work to move faster where the data inventory and role model already exist, and slower where permissions were granted case by case over years. Ask for milestones tied to specific systems rather than a single end date.

What must our team provide before an implementation partner starts?

The team must supply access to the systems in scope, the list of data types and their owners, and the business rules that say who needs which data. The following are typically needed:

A current data inventory or a list of sensitive data stores (Safeguard 3.2)
Identity sources and group structures used for access decisions
Named data owners who can approve or reject access
Change windows and test environments for each system

Without these inputs, rules are guesses and will fail review.

Can our in-house team configure data access control lists without outside help?

Yes, an in-house team can do this work if it has the database, application and file system administration skills, and if data owners engage in the access model. Outside help is most useful when the team lacks experience across several platforms, when permissions are tangled, or when the team needs evidence prepared for an assessment. The organization always owns its controls. An implementation partner prepares systems and evidence, but only an independent auditor or assessor issues reports.

How does Safeguard 3.3 relate to Safeguards 3.2 and 5.1?

Safeguard 3.2 (the data inventory) and Safeguard 5.1 (the account inventory) are prerequisites for measuring Safeguard 3.3, according to the CIS Controls Assessment Specification for v8.1. The data inventory tells you which data exists and where, so you know which access lists to build. The account inventory tells you which identities exist, so you can match them to need to know. Safeguard 4.1, the secure configuration process, also feeds the measurement. Skipping these inventories usually means access lists cover only the systems people remember.

What will an auditor check for Safeguard 3.3, and what will they not do?

An assessor will check whether access permissions on data follow documented need-to-know decisions across databases, applications and file systems, and whether those permissions are configured and kept that way. The CIS Controls Assessment Specification defines 8 measures for this Safeguard, combined into two metrics: completeness of user access control and properly configured assets. An auditor will not design your access model, configure your systems or certify that your data is secure in general. Those activities remain with your organization or your implementation partner, and only the independent auditor issues the report.

Which open-source tools can produce evidence for data access control lists?

Open-source tools can produce some of the evidence, mainly access rule definitions and review records. For example, Nextcloud's File Access Control app can deny upload, modification, deletion, download and sync based on rules such as user group, IP address and file name. For periodic review, midPoint supports access certification campaigns in which designated reviewers decide to keep, change or revoke access items within a set timeframe. Confirm with each vendor that a feature fits your systems before relying on it, since rule coverage varies by platform.

How DeployOpen scopes and prepares data access control evidence

DeployOpen scopes data access control work as a fixed-scope engagement, with the scope, deliverables and timelines agreed in writing before any configuration begins. For Safeguard 3.3, the written scope should name the data stores in play (specific databases, applications and file shares, whether on premises or in the client's cloud accounts), the user populations and groups whose access is in question, and the decision owners who approve each access model. Because the Assessment Specification lists the data inventory (3.2), secure configuration (4.1) and the account inventory (5.1) as prerequisites, the scope should also state which of those outputs DeployOpen will rely on and which the client must supply. Ask for that list in any quote, since missing prerequisites are the most common reason measurement stalls.

DeployOpen configures and documents self-hosted open-source platforms inside the client's own infrastructure, so the access rules, group mappings and configuration files stay under the client's control. Typical deliverables for this Safeguard include a written access model per data store, the configuration exported as version-controlled files, and a record of who approved each rule. Where a platform supports file-level rules, such as the File Access Control app for Nextcloud, which can deny upload, download, sync and modification based on group, IP address, file name or MIME type, the rule set and its test results should be documented together. For identity governance, midPoint access certification campaigns can give designated reviewers a fixed window to keep, change or revoke access items, which produces dated review evidence. Confirm with DeployOpen during scoping which of these components your environment actually needs.

DeployOpen prepares systems, controls and evidence for an assessment, but it does not issue audit reports, attestations or certifications. Those come only from an independent auditor, assessor or certification body, which the organization selects and pays directly. Ask any implementation partner to show, in writing, how the evidence maps to the framework your assessor will use, and ask the assessor early which samples and time periods they will test. Clarify with both parties who owns the access decisions after handover, because a control that no named person reviews will fail the Safeguard's measures regardless of how well it was configured at go-live.

Safeguard 3.3 Configure data access control lists