Managerial & Access Controls
Not all data deserves the same protection. This topic is about reading a dataset's sensitivity and state, then granting exactly the access it needs — no more.
The protection a piece of data gets depends on two things: what it is (its classification — public, or regulated like PII, PHI, PCI) and where it is (its state — at rest, in transit, or in use). More sensitive data earns stronger controls, and some classes are governed by law.
Once you know what you're protecting, access control decides who can do what. You'll choose an access-control model, apply the principle of least privilege, and configure file permissions on a Linux system — rwx for owner, group, and others.
Classify the Data
Sort data by sensitivity and state — at rest, in transit, in use — and apply protection to match.
5.2.A · ClassificationChoose the Model
RBAC, RuBAC, DAC, or MAC — each decides which subjects may operate on which objects.
5.2.C · Access modelsSet the Permissions
Configure Linux file access — read, write, execute for owner, group, and others.
5.2.D · PermissionsYour organization stores customer PII, patient PHI, and payment PCI — each governed by its own rules. Leadership wants a plan: classify every dataset, protect it in each state, choose an access-control model, and lock down file permissions to the minimum each role needs.
AP Learning Objectives
- 5.2.AExplain how the state or classification of data impacts the security applied to it.
- 5.2.BIdentify managerial controls related to application and data security.
- 5.2.CDetermine an appropriate access control model to protect applications and data.
- 5.2.DConfigure access control settings on a Linux-based system.
Security is proportional. The more sensitive the data and the more exposed its state, the stronger the controls — and the tighter the access. Least privilege is the throughline: give every subject exactly the access it needs to do its job, and nothing more.
What you'll be able to do: classify data by type and state, match access-control models to scenarios, build least-privilege role grants, configure Linux file permissions, and plan end-to-end protection for a sensitive dataset.
Classification, State & Access
Two questions shape every protection decision: how sensitive is the data, and what state is it in?
Data exists in three states. At rest, it sits on a drive — protect the physical drive and encrypt it so theft doesn't expose it. In transit, it moves between devices — protect the media and encrypt it so interception doesn't expose it. In use, it's being processed by software or a person — and here it must be unencrypted to be used, so access controls decide who may view or edit it.
Data is also classified by sensitivity. Regulated categories carry legal obligations: PII (names, SSNs, addresses), PHI (health records), and PCI (payment-card data). Access itself is governed by an access control model — defining which subjects may perform which operations on which objects — always guided by least privilege.
Diagram · Data classification ladder
Diagram · Access control decision flow
Data State Security Selector
Lab · 5 casesIdentify the state each piece of data is in. The feedback shows how to protect it.
Concept Check
30 secWhich state must data be in unencrypted form?
Data Types, Policies & Models
The regulated data classes, the managerial policies that govern them, and the access-control models.
| Class | Examples & regulation |
|---|---|
| PII — personally identifiable information | Name, SSN, address, DOB, email, biometrics. Covered by the Privacy Act of 1974 (and COPPA for children under 13). |
| PHI — protected health information | Test results, treatment and hospital records, doctor notes. Covered by HIPAA (1996). |
| PCI — payment card information | Card name, account number, expiration, CVV. Regulated by PCI-DSS. |
| Term | What it does |
|---|---|
| Cryptography policy | Approved algorithms, key lengths, key-generation and key-storage requirements. |
| Web application security policy | When/how apps are assessed and timelines for remediating vulnerabilities by risk. |
| RBAC — role-based | Access is granted by the subject's assigned role (e.g., "accountant" → payroll). |
| RuBAC — rule-based | Rules allow/deny access (e.g., no access outside working hours); layered on another model. |
| DAC — discretionary | Object owners set who else gets access; admins can override. |
| MAC — mandatory | Strict levels set by an external admin; access depends on subject vs object level. |
| Bell-LaPadula | A MAC model: "write up, read down" — no reading above your level, no writing below it. |
| Least privilege | Give each subject exactly the access it needs — no more. |
Access Control Model Matcher
Lab · 5 casesRead each scenario and name the access-control model it describes.
What the Exam Rewards
This topic is Mitigate Risk — skills 2.C (evaluate the impact of protective strategies) and 2.D (implement and log mitigations).
Match classification to obligation. Know which law covers which data: PII → Privacy Act, PHI → HIPAA, PCI → PCI-DSS. The data's class drives the required controls.
Know the models cold. RBAC = by role, RuBAC = by rule, DAC = owner decides, MAC = external levels, Bell-LaPadula = write up / read down.
Common MCQ traps
"Bell-LaPadula is 'read up, write down'."
It's the reverse — write up, read down: no reading above your level, no writing below it.
"In DAC, an administrator sets all access."
In DAC the object owner sets access; admins/superusers can override. External-admin levels are MAC.
"Encrypting data at rest is enough for all states."
Each state needs its own protection — and data in use must be decrypted, so access controls matter there.
Analyst note: the org's patient records are PHI (HIPAA). Encrypt them at rest and in transit; while in use, restrict access with RBAC so only clinical roles can view or edit. Layer a RuBAC rule denying access outside working hours, and grant every role the least privilege it needs.
Data Classification Board
Lab · ClassifySelect each data example and drop it into the class it belongs to. The feedback names the governing law.
PII
Privacy Act
PHI
HIPAA
PCI
PCI-DSS
Public
Non-sensitive
Configure Linux File Permissions
The configure skill. Toggle read, write, and execute for each entity and watch the symbolic string, numeric value, and chmod command update live.
Diagram · Permission matrix (Linux rwx)
Linux Permissions Simulator
Lab · Configure (2.D)Toggle each permission on or off. Then try to hit the target permission shown below.
| read (4) | write (2) | execute (1) |
|---|
Misconceptions That Cost Points
Each is a planted wrong answer. Learn to see the trap.
"chmod 750 gives everyone full access."
It's owner rwx (7), group r-x (5), others none (0). Each digit is one entity.
"More access is safer — give admins everything."
Least privilege says grant exactly what's needed. Excess access widens the attack surface.
"RBAC and RuBAC are the same."
RBAC grants by role; RuBAC grants by rule (like time-of-day) and layers on top of another model.
"Write access lets you run a program."
That's execute. Write lets you change a file; execute lets you run a binary.
"All sensitive data needs the same protection."
Security scales with classification and state — regulated data gets the strongest controls.
"The order of rwx can vary."
It's always read, write, execute — and always owner, then group, then others.
Least Privilege & the Plan
A quick chmod reference, plus two labs: grant least-privilege access per role, then plan full protection for a dataset.
| Digit | Permissions granted |
|---|---|
0 | none |
1 | execute |
4 | read |
5 | read + execute (4+1) |
6 | read + write (4+2) |
7 | read + write + execute (4+2+1) |
Least-Privilege Builder
Lab · GrantGrant each role the minimum access it needs to the patient-records system, then check against least privilege.
Sensitive Data Protection Planner
Lab · Plan (2.D)Assemble an end-to-end protection plan for a dataset, then generate it.
Prove the Protection Plan
Five AP-style questions with instant feedback, then a snapshot to lock it in.
Mini AP-Style Quiz
Lab · 5 questionsChoose one answer per question, then submit for scored feedback with explanations.
Five Takeaways
State drives protection. Encrypt at rest and in transit; data in use must be unencrypted, so use access controls.
Classification drives law. PII → Privacy Act, PHI → HIPAA, PCI → PCI-DSS.
Pick the right model. RBAC by role, RuBAC by rule, DAC owner-set, MAC external levels (Bell-LaPadula: write up, read down).
Least privilege always. Grant exactly the access needed — subjects, operations, objects.
Permissions are rwx. read 4, write 2, execute 1, for owner, group, others — set with chmod.
Final AP exam tip: for a protection question, name the data's class and state, then the matching control — "PHI at rest → encrypt the drive; in use → RBAC by clinical role." For chmod, translate each digit: 7=rwx, 5=r-x, 4=r--, 0=none.
One mistake to avoid: don't over-grant. The safest permission set is the smallest one that still lets each role do its job — that's least privilege in action.
Practice — attempt these now.
AP-style assessments aligned to this lesson. Time them.
Unit 5 Topic 5.2 — Protecting Applications and Data: Managerial Controls and Access Controls
AP-style topic practice assessment
Unit 5 Topic 5.2 — Sensitive Data Access-Control Analysis
AP-style topic practice assessment