52
NICE work roles in the reference list, plus 21 organizational roles from the same source
511
objectives with a suggested primary role (NIST SP 800-171 Rev 3)
2
client tables, both typed during the interview
0
jobs or buttons: this pass is entered by hand
The data model
Two client tables, bridged to a shared role list. Solid lines are links stored in the data; the dashed one is the join no job walks yet.
Link that exists
Join the design intends, not yet built
People and Client_Roles are empty in the template and never touched by reference pushes. Roles and Objective_Role_Map are reference data, identical in every client base.
1
Capture: people first, then roles
Typed during the interview, in two views built for it.
- People. In the "Interview: People" view, one row per real person: name, their actual job title as they say it, email.
- Roles, in the client's words. In the "Interview: Roles & NICE mapping" view, one row per role the client actually has ("IT Director", "Shop Floor Supervisor", "our MSP"), with a sentence on what it does.
- The mapping decision. Link each client role to the standard role or roles it resembles, or to none.
- Assign people. A person can hold several roles, and a role can be vacant.
Done when every person has a role and every role has a mapping decision. "No close match" is a decision; an untouched role is not. Nothing checks this yet; the runbook states it.
The fields
| Table | Field | Holds |
|---|
People | Name, Title, Email | The person, with their title verbatim |
People | Client Roles | Link to the roles they hold (the same link as Assigned People, seen from the other side) |
Client_Roles | Name, Purpose / Description | The role as the client names and describes it |
Client_Roles | Maps To NICE Role(s) | Link to zero, one or many reference roles |
2
Translate: the mapping is one link
Adopt a standard role, define a custom one, or translate between them: all the same action.
- No separate "subscribe" flag. Creating a client role and linking it to a standard role is the subscription. A tight link, a loose one, or no link at all each records something true about the client.
- Why a standard list at all. It lets one mapping of objectives to roles be reused across every client, and it keeps role names consistent inside our own library.
- Why the client's words stay primary. A standard role name means little to a 40-person machine shop. Anything the client reads should say "IT Director shall review audit logs", not the standard role's name.
- Why ownership points at a role, not a person. A document's Owning Role links to a client role, because positions outlast the people in them. The SSP's System Owner and security officer are the exception: they name people, because the plan has to record who holds the responsibility now.
Where the reference list came from
| Reference table | Rows | What it is |
|---|
Roles | 73 | The 52 work roles of the NICE Workforce Framework (components v1.0.0), plus 21 organizational roles (risk, compliance, asset and process owners, change control, physical security, continuity) that the source spreadsheet adds |
Objective_Role_Map | 511 | One suggested primary operator per NIST SP 800-171 Rev 3 objective, imported from the same spreadsheet and marked advisory. The spreadsheet's full responsibility grid (13,094 rows) was deliberately left out |
Role_Technology_Map | 0 | Empty by design: which role runs which product is specific to each client |
3
Use: what reads it today
Some of the mapping is load-bearing now; some is captured for a join that isn't built.
| Consumer | Reads | Status |
|---|
| SSP generator | System Owner and System Security Officer, as name, title and email from People | Live. A missing System Owner keeps the SSP marked DRAFT |
| Policy statement authoring | Objective_Role_Map, to give each Rev 3 statement its responsible role | Used once, when the library was written |
| Client documents | Owning Role, a link to a client role | Stored, not yet read by any job |
| Evidence requests and the portal's owner filter | A role label copied from the evidence library, not the client's roles | Planned: route each request to the client's own person |
| Client-facing statements | Standard role names today | Planned: swap in the client's role name through the mapping |
The {{it_lead}} variable in policy statements is separate on purpose: a single client-wide value such as "IT Manager" or the MSP's name, filled in with the client's other variables rather than looked up from roles.
The planned join. Objective → its suggested standard role → the client roles mapped to that standard role → the people assigned to them. Every link in that chain exists; no job walks it yet, so today a consultant does the lookup by hand.
Decision log
The calls that shaped people and roles, and when they were made.
| Decision | Why | When |
|---|
| Import only the primary operator per objective | The full responsibility grid is one vendor's judgment, too much upkeep for its value | 2026-07-16 |
| Leave the role-to-technology map empty | Which role runs which product is client-specific | 2026-07-16 |
| People and client roles as one mechanism; the link is the subscription | No flag to keep in sync with the link | 2026-07-17 |
| Give policy statements specific responsible roles instead of one blanket role | A statement should name who does the work | 2026-07-19 |
| Document ownership points at a role | Ownership should survive staff turnover | 2026-07-20 |
| SSP owner and security officer point at people | The plan must record who holds security responsibility | 2026-07-23 |
Keep {{it_lead}} separate from roles | Often an outside MSP, and one value per client | 2026-07-31 |
Known gaps
- The objective-to-person join isn't built. Evidence requests carry a role label from the library, so they can't yet name the client's own person.
- The objective-to-role map covers Rev 3 only. A CMMC Level 2 assessment uses the Rev 2-based objectives, which have no suggested roles yet.
- Mixed role labels. A handful of evidence library entries use labels such as "GRC / Compliance" that aren't in the reference list, so the portal's owner filter mixes the two vocabularies.
- No completeness check. "Every person has a role, every role has a decision" is a runbook sentence, not a computed flag.
- Outside providers aren't modeled. The tables hold the client's own staff; an MSP's people appear only as a role name or a variable.
- Hand entry only. A client worksheet or portal editor for keeping people and roles current is logged, not built.