# Security, ACLs, and Data Control

> Chapter 16 of the Courseiva SERVICENOW-CSA curriculum — https://courseiva.com/learn/servicenow-csa/security-acls-and-data-control

**Official objective:** 1.5 — Implement security through Access Control Lists (ACLs), security rules, and data control.

## Introduction

Security, ACLs, and Data Control is the set of rules that determines who can see, edit, or delete information inside a ServiceNow instance. For the SNOW-CSA exam, you must understand that without these rules, any user could change any record — including deleting your company's entire configuration database. This chapter teaches you how to protect data the same way a bouncer controls entry to a club.

## The Apartment Building Key System Analogy

Seven different tenants live in a three-story apartment building. Each tenant has a key to their own flat, but the building manager must decide who can access the laundry room in the basement, who can enter the rooftop garden, and who can open the mail room door. This is exactly how Access Control Lists (ACLs) work in ServiceNow — they manage who can see, edit, or delete specific records based on a set of rules.

In the building, the manager sets rules: "Tenants in flat 1A can use the laundry room from 8am to 8pm" and "Only tenants who signed the rooftop waiver can enter the garden." If a tenant tries to open the laundry door at 9pm, the lock refuses — even if their key fits. That is a security rule: it checks the condition (time of day) before granting access. If a tenant moves out, the manager can instantly revoke their key without changing everyone else's locks — that is data control. The manager's master key is like an admin role: it overrides every individual lock rule. But the manager never hands out the master key unless absolutely necessary, because one lost master key could compromise the entire building.

Your ServiceNow instance (the software platform) is that apartment building. Every record — a user profile, a support ticket, a configuration item — is a room or an object. An ACL is the lock on each door. A security rule is the condition (like time of day or user department) that the lock checks. Data control is the list of who holds which keys and the ability to revoke them instantly. When you study for SNOW-CSA, you must understand that every door in your apartment building needs a lock, and you must know how to set each lock's rules without accidentally locking out the building manager.

## Core explanation

ServiceNow is a platform where multiple people — called users — log in to manage IT services, track problems, and handle requests. Every user needs access to some data, but not all users should see all data. A help desk agent might need to view a user's personal phone number to resolve a ticket, but a developer from a different team should not. This is where Access Control Lists (ACLs) come in.

An ACL is a rule that the system evaluates every time someone tries to read (view), write (edit), create (add new), or delete a record. Each ACL contains three main parts: the type (read, write, create, or delete), the condition (who or what triggers the rule), and the result (grant or deny access). By default, ServiceNow denies access unless an ACL explicitly grants it. This is called the principle of least privilege — you start with everything locked, then open only what is necessary.

Let us define the critical terms:

- Operation: The action the user wants to perform. The four operations are read (view), write (edit), create (add a new record), and delete (remove a record). Each operation can have its own ACL.

- Condition: A logical test that checks attributes of the user (their role, department, manager), the record they are trying to access (its assignment group, state, priority), or the current time or date. If the condition is true, the ACL grants or denies access depending on its type.

- Role: A label assigned to a user, such as "admin", "itil", "user", or "helpdesk". Roles are the easiest way to group users with similar permissions. For example, an ACL can say "only users with the role 'admin' can delete records".

- Script: A small piece of code written in JavaScript that defines a more complex condition. Scripts are used when a simple role check is not enough, for example, "allow access only if the user's manager is the record's assignee and the current time is between 9am and 5pm".

- Module: A section of the ServiceNow interface, such as Incident, Change Request, or User Administration. ACLs are often applied to specific modules or tables (the database storage for a type of record).

Now, how does an ACL actually work? When a user clicks on a link or tries to submit a form, ServiceNow checks the relevant ACLs in a specific order. First, it looks for ACLs defined directly on the table (the general rule). If none match, it looks for ACLs on the specific record type (the record-level rule). If still nothing matches, the system denies the operation by default. This is known as the "deny by default" rule — no ACL = no access.

Security rules are an additional layer. They allow administrators to set conditions that override ACLs in certain situations. For example, a security rule might say "lock all incident records with priority 1 (critical) during weekends, regardless of the user's role". Security rules are evaluated after ACLs and can either grant or deny access based on conditions like time, assignment group, or record state.

Data control refers to the broader practice of managing who has access to what, including not just ACLs and security rules but also the ability to revoke or modify permissions without affecting other data. In ServiceNow, data control also includes high-security settings (a toggle that marks a record as restricted) and the ability to see audit logs (records of who accessed or changed data).

Why do ACLs exist in the first place? Before ACLs were standard, software often used simple password-based access or blanket permissions (everyone sees everything). This led to data leaks and compliance failures. ACLs provide granular control — you can let a user read a ticket but not delete it, or let someone see a database table but not export its contents. In ServiceNow, ACLs are the foundation of data security for the enterprise.

To summarise, a ServiceNow instance has millions of records. Without ACLs, every user is a potential risk. ACLs give you the power to say: this person can see this incident but only during business hours, and only if they are in the same team as the assignee. That is the difference between a secure, compliant platform and a data leak waiting to happen.

## Real-world context

Imagine you work as a ServiceNow administrator for a company called TechVille. TechVille has 500 employees, 100 of whom use ServiceNow daily. The company has an Incident Management module where employees submit IT support tickets. Each ticket contains sensitive information: the user's name, department, the nature of the problem (e.g., "password reset" or "laptop broken"), and sometimes the employee's personal notes.

Your first task is to set up ACLs so that:

- The employee who submitted a ticket can only read their own ticket and cannot edit or delete it.
- The help desk team (role: helpdesk) can read, edit, and update all tickets but cannot delete them.
- The manager of a department can see all tickets submitted by people in their department.
- Only the system administrator (role: admin) can delete tickets.

Here is what you would do step by step:

1. Navigate to the Access Controls (ACL) module in ServiceNow.
2. Create a new ACL for the Incident table. Set the operation to "read". In the condition field, you specify "if the user is the caller of the ticket, grant access". This is a condition script.
3. Create another ACL for "write" on the Incident table. Here, you set the condition to require the role "helpdesk". That means only users with that role can edit tickets.
4. Create a third ACL for "delete" on the Incident table. Set the condition to require the role "admin".
5. For the manager scenario, you write a script that checks if the current user is the manager of the user who submitted the ticket. If yes, grant read access.

Now, what happens when a new employee, Priya, submits a ticket about her broken laptop? When she clicks "Submit", ServiceNow evaluates all ACLs. It checks the "read" ACL for Priya: since she is the caller, the condition is true, and the operation is granted. When a help desk agent, Raj, tries to view Priya's ticket, the system checks the "read" ACL again. Raj is not the caller, so the first condition fails. But the system then looks at the next ACL: the one for helpdesk role on read. Raj has that role, so access is granted. When Raj tries to delete the ticket, the system checks the "delete" ACL and denies him because he lacks the admin role.

Later, TechVille's security policy changes: all tickets related to password resets must be hidden from everyone except the security team. You add a security rule that checks the "short description" field of the ticket. If it contains "password reset", the system denies read access for everyone except users with the role "security_team". This security rule overrides the existing ACLs for those specific tickets.

What you actually do as an IT professional: you spend hours planning ACLs before implementing them, because a mistake can lock out entire departments or expose private data. You also run ACL simulation tests (a tool in ServiceNow) to check how a specific user would be affected by new rules. You document every ACL because six months later, a new administrator will need to understand why a certain rule exists. And you regularly audit ACLs to remove outdated rules — for example, when a project ends and a temporary role should be deleted.

The real value of ACLs is that you can enforce compliance (such as GDPR or HIPAA) without rewriting code. You simply adjust a few rules, and suddenly only authorised personnel can see personal data. That is why SNOW-CSA tests this topic heavily: ACLs are the first line of defence in any ServiceNow deployment.

## Exam focus

The SNOW-CSA exam (ServiceNow Certified System Administrator) dedicates a significant portion to Security, ACLs, and Data Control — specifically objective 1.5. Expect between 12 and 15 questions directly on this topic, many of which will test your ability to identify the correct order of ACL evaluation and the default behaviour when no ACL matches.

Key topics the exam loves to test:

- The four operations: read, write, create, delete. You must know them by heart. A common question gives a scenario and asks which operation is required — for example, "A user can view a ticket but cannot change its state." The answer is that the user has read access but not write access.

- The default behaviour: if no ACL matches a user's request, access is denied. This is called "deny by default". The exam will present a scenario where a user cannot see a record, and the answer is often "there is no ACL granting them access".

- The order of ACL evaluation: system first checks table-level ACLs, then record-level ACLs. If neither matches, access is denied. Security rules are evaluated after ACLs and can override the result.

- Role inheritance: if a user has multiple roles, they inherit the permissions of all roles. For example, if a user has the "itil" role and the "user" role, and "itil" allows write but "user" denies write, the system has a conflict resolution rule (it uses the most permissive result, but only among matched ACLs). The exam tests this conflict resolution.

- Scripts vs condition builder: the exam tests when you need a script versus a simple condition. For example, if you need to check the record's state against the user's department, you must use a script because the condition builder cannot handle cross-table comparisons.

- High security settings: a checkbox on a record that makes it visible only to users with the 'admin' role, regardless of ACLs. The exam loves to ask: "A record is marked as high security. Who can see it?" Answer: only administrators.

- ACL simulation: a feature that lets you test what a specific user can see before implementing changes. The exam may ask which tool you use to troubleshoot access issues.

Common traps they set:

- Trap: "What is the default access when no ACL exists?" Some answers try to trick you into saying "read access is granted" or "depends on the table". The correct answer is always "deny".

- Trap: They give a scenario where a user has both a 'deny' and a 'grant' ACL for the same operation. Many beginners think deny always wins, but in ServiceNow, if an ACL grants access, that is the result, unless a higher-priority deny exists. The system uses a priority system: it does not simply take the first match.

- Trap: Confusing table-level ACLs with record-level ACLs. Table-level ACLs apply to all records in a table unless a specific record-level ACL overrides them. The exam may ask which level takes precedence. Record-level wins.

- Trap: Questions on security rules that override ACLs. Beginners forget that security rules are evaluated after ACLs and can change the final outcome.

Concepts you must memorise exactly:

- The definition of 'read', 'write', 'create', 'delete'.

- The difference between a role and a user. A role is like a badge; a user is the person wearing it.

- Know that multiple ACLs can match, and ServiceNow uses the most permissive result among matching ACLs.

- Understand that any authenticated user (logged-in person) has at least the 'user' role by default.

- Know what 'sys_user' table is (the table storing all user records) and that ACLs on it control access to user profiles.

Practise with sample exams: search online for SNOW-CSA practice tests and focus on ACL questions. Many traps reappear. If you can explain to a colleague why a specific user cannot see a ticket, you have mastered this section.

## Step by step

1. **Identify the table and operation** — Determine which table (database of records, like Incident or User) needs an ACL and which operation (read, write, create, or delete) you are controlling. For example, you want to prevent non-helpdesk users from editing incident records, so you need a 'write' operation ACL on the Incident table.
2. **Open the Access Controls module** — Navigate to 'System Security' -> 'Access Controls (ACL)'. This is where all ACLs are created and managed. You will see a list of existing ACLs and a button to create a new one. This step matters because if you go to the wrong module, you cannot create an ACL.
3. **Create the ACL rule** — Click 'New' and fill in the Type (e.g., 'record' for record-level ACL or 'table' for table-level), the Operation (read, write, create, delete), and the Name (a descriptive name like 'Incident Write - Helpdesk Only'). Then define the condition. You can use the condition builder for simple checks (like role equals helpdesk) or a script for complex logic (like checking the record's state and the user's department). This is the core of the ACL.
4. **Configure the condition and role** — In the 'Condition' section, either choose 'Requires role' and select 'helpdesk' from the list, or write a script. If you write a script, ensure it returns true (grant) or false (deny). For example, a script might check if the current user's manager is the record's caller. Test the script using the 'Test ACL' button to avoid errors later.
5. **Test with ACL simulation** — ServiceNow has an 'ACL Simulation' feature under 'System Security' -> 'ACL Simulation'. Enter a test username and the record they are trying to access, and run the simulation. It will show which ACLs matched and the final access decision. This step is critical because it catches mistakes before they affect real users. If the simulation shows access denied for someone who should have it, go back and adjust the ACL condition.
6. **Document and deploy** — After testing, add a short description to the ACL explaining why it exists and who approved it. Then save the ACL. It becomes active immediately. Document the ACL in a spreadsheet or knowledge article for future administrators. This step is often skipped but matters for long-term maintainability — without documentation, another admin might delete or modify the ACL unknowingly.

## Comparisons

### Table-level ACL vs Record-level ACL

**Table-level ACL:**
- Applies to all records in a table by default
- Has lower priority than record-level ACLs
- Used for broad rules like 'helpdesk can read all incidents'

**Record-level ACL:**
- Applies to a specific record or set of records
- Overrides table-level ACLs for those records
- Used for exceptions like 'only user X can read this specific incident'

### ACL vs Security Rule

**ACL:**
- Controls read, write, create, or delete operations
- Evaluated first in the access check sequence
- Uses conditions and roles for simple access control

**Security Rule:**
- Adds extra conditions like time or state
- Evaluated after ACLs and can override their result
- Used for advanced scenarios like 'lock tickets during weekends'

### Role-based access vs Script-based access

**Role-based access:**
- Simple: uses predefined roles like 'admin' or 'helpdesk'
- Fast to set up and maintain
- Cannot handle cross-table logic or complex conditions

**Script-based access:**
- Custom: uses JavaScript to define unique conditions
- Slower to set up but highly flexible
- Can check relationships between tables, like manager of the caller

### Read operation vs Write operation

**Read operation:**
- Allows user to view the record's fields
- No ability to change or update data
- The most commonly granted operation

**Write operation:**
- Allows user to edit and update existing records
- Does not allow deletion
- Requires separate ACL from read

## Diagram

_Flowchart showing how a user request is processed: ACLs are evaluated first, then security rules override if needed, with 'deny by default' when no ACL matches._

```mermaid
flowchart TD
    A[User Request] --> B{ACL Evaluation}
    B -->|No matching ACL| C[Deny by Default]
    B -->|Matching ACL found| D{ACL Result}
    D -->|Grant| E[Security Rule Check]
    D -->|Deny| F[Access Denied]
    E -->|Security Rule allows| G[Access Granted]
    E -->|Security Rule denies| F
    C --> H[End - No Access]
```

## Common misconceptions

- **Misconception:** I can just create one ACL for 'read' that covers all users, and it will automatically apply to every record in the table. **Reality:** An ACL must explicitly specify which roles, conditions, or scripts determine who is granted access. A single 'read' ACL without conditions grants access to all authenticated users, which is rarely the goal. You must define the condition precisely. (Beginners think one ACL equals universal permission because they do not realise that an ACL without conditions acts as a blanket grant. ServiceNow's default is deny, so a blank ACL actually grants access to everyone — which is dangerous.)
- **Misconception:** Security rules and ACLs are the same thing, so I only need to configure one of them. **Reality:** ACLs control basic operations (read, write, create, delete) and are evaluated first. Security rules are evaluated after ACLs and can override or restrict access based on additional conditions like time or record state. They are complementary, not interchangeable. (The names sound similar, and both affect access. Beginners confuse the two because they both appear in the 'Access Controls' module. The exam loves to test this distinction.)
- **Misconception:** If a user has the 'admin' role, they can see all records regardless of ACLs. **Reality:** By default, users with the 'admin' role are not automatically granted access to all records. Many organisations remove the admin role from most users because it gives excessive permissions. ACLs still apply to admins unless there is an ACL explicitly granting access to the admin role. (In smaller systems like home Wi-Fi, being an admin means total control. In enterprise platforms like ServiceNow, admins can be restricted by ACLs for compliance reasons, which contradicts the everyday understanding of 'admin'.)
- **Misconception:** Creating an ACL for 'delete' automatically prevents users from updating records. **Reality:** The 'delete' operation only prevents deletion. To prevent a user from editing a record, you need to write a 'write' ACL that denies access. Each operation is independent. (People often conflate 'delete' with 'edit' because both involve changing data. In ServiceNow, they are completely separate operations with separate ACLs.)
- **Misconception:** An ACL that denies access always overrides an ACL that grants access. **Reality:** ServiceNow uses a 'most permissive wins' rule among matched ACLs. If one ACL grants read access and another denies read access, the grant wins unless the deny ACL has a higher priority number (lower number = higher priority). (This is counterintuitive because in real life, one 'no' usually overrides any number of 'yes's. Beginners assume the same here, but ServiceNow's logic works differently.)

## Key takeaways

- The default behaviour in ServiceNow is 'deny by default' — if no ACL matches the user's request, access is automatically denied.
- An ACL consists of an operation (read, write, create, delete), a condition (role, script, or condition builder), and a result (grant or deny).
- Security rules are evaluated after ACLs and can override the ACL result based on additional conditions such as time, record state, or assignment group.
- Record-level ACLs take precedence over table-level ACLs for individual records, but if no record-level ACL matches, the table-level ACL applies.
- The 'admin' role does not automatically bypass all ACLs; ACLs still apply to admin users unless explicitly configured otherwise.
- Use ACL simulation before deploying new rules to test how specific users will be affected, preventing accidental lockouts or data exposure.
- Each operation (read, write, create, delete) requires a separate ACL — one ACL cannot control multiple operations.
- The 'high security' checkbox on a record makes it visible only to users with the 'admin' role, overriding all other ACLs for that record.

## FAQ

**What is an ACL in ServiceNow, and why do I need it for the CSA exam?**

An ACL (Access Control List) is a rule that determines whether a user can read, write, create, or delete a record. The CSA exam tests ACLs heavily because they are the primary way to secure data in ServiceNow, and you must understand how to create and troubleshoot them.

**How do I check if an ACL is working correctly?**

Use the ACL Simulation tool in ServiceNow (System Security -> ACL Simulation). Enter a user and a sample record, and the simulation shows which ACLs matched and the final access decision. This is the official troubleshooting method.

**Can I create one ACL that controls both read and write operations?**

No. Each ACL is tied to a single operation (read, write, create, or delete). You must create separate ACLs for each operation you want to control. For example, you need one ACL for read and a different ACL for write.

**What happens if a user has no roles assigned?**

A user with no roles still has the default 'user' role, which is assigned automatically to all authenticated users. That role may give them basic access to some tables (like the ability to view their own profile), but without specific ACLs, most operations are denied by default.

**How do security rules differ from ACLs?**

ACLs control the basic operations (read, write, create, delete) and are evaluated first. Security rules are evaluated after ACLs and can override the result based on additional conditions like time, record priority, or assignment group. Think of ACLs as the main lock and security rules as an extra deadbolt.

**What does 'deny by default' mean in the context of ServiceNow ACLs?**

It means that if no ACL matches a user's request, the system automatically denies access. This is a security principle: you start with everything locked and only open specific doors via ACLs. It prevents accidental data exposure when a new table is created without any ACLs.

## Check your understanding

1. **What is the default access result in ServiceNow when no ACL matches a user's request?**

   Answer: Access is denied. This is called 'deny by default'.

2. **What are the four operations that ACLs can control?**

   Answer: Read, write, create, and delete.

3. **If a user has both a 'grant' ACL and a 'deny' ACL for the same operation, which one wins?**

   Answer: The 'grant' wins, because ServiceNow uses the most permissive result among matched ACLs, unless the deny ACL has a higher priority (lower number).

4. **What tool in ServiceNow can you use to test what a specific user will see before applying an ACL change?**

   Answer: The ACL Simulation tool, found under System Security -> ACL Simulation.

5. **What is the difference between a table-level ACL and a record-level ACL?**

   Answer: A table-level ACL applies to all records in a table by default, while a record-level ACL applies to a specific record and overrides the table-level ACL for that record.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/servicenow-csa/security-acls-and-data-control