Roles and Permissions Matrix

Goal

A roles and permissions matrix assigns to every role, for every function of a solution, the authority it holds over that function: create, read, update, delete, execute, approve or nothing at all. A filled cell permits, a marked cell refuses. The row carries either the activity itself or the object the authorities bear on, depending on the convention in force. The technique answers a question every system raises and nobody asks out loud: which function requires which access. Where it goes unasked, the answer is produced during configuration, by a developer or an integrator who infers it from whatever seems convenient.

The useful half of that design decision is the refusal. Letting one role read a file is an unremarkable sentence; refusing that same read to four other roles is the requirement the system will have to enforce, test and prove. What the grid decides downstream is considerable: the role model that will be configured in the target solution, the segregation of duties constraints that must hold, the reach of the audit log and the recertification campaigns that follow for the life of the system.

The deliverable comes in four inseparable pieces. The filled grid, one row per function, one column per role, one authority per cell. The role definition list, one line per role: which job family it covers, who answers for it, who assigns it. The constraints a grid cannot draw, mutually exclusive roles, scopes of the "own file only" kind, inheritance and delegation rules. And the legend, which states what a cell without an authority is worth: silence means refusal, the platform denies by default, and that sentence written once turns a table into a requirement.

For processing governed by Swiss law, this grid is the documentary form of an obligation. The FADP requires the controller to apply data protection by design (art. 7) and to guarantee a level of data security appropriate to the risk through technical and organisational measures (art. 8). The DPO sets the security objectives, confidentiality among them (art. 2), and files data access control among the measures that guarantee that confidentiality: the controller takes appropriate measures to ensure that "authorised persons only have access to those personal data that they require to fulfil their tasks" (art. 3 para. 1 let. a).

Usage

When to use it

• Distinct user populations on one solution: job families whose rights cannot be identical.
• Sensitive or regulated data: health, human resources, finance, where every read must be justified.
• Segregation of duties required: separate who prepares from who approves, before configuration merges them.
• Audit or certification announced: establish who could do what, before the first review.
• Configuring a package or a cloud service: confront the product's role model with the real job families.
• Rights in an existing system gone inconsistent: rebuild a target, then compare it with the entitlements actually granted.
• Interfaces, batch jobs and service accounts: give them a column before they are handed every right.
• Outsourcing or insourcing an activity: fix what the provider sees while the contract is still being negotiated.

When not to use it

• One population with identical rights: a one-column grid teaches nothing, write the single set of authorities as a non-functional requirement.
• Rights that depend on data or context: write attribute rules rather than multiply roles, where access turns on record ownership, an amount threshold or a time of day.
• Functions or organisation not yet stable: the grid will be rebuilt entirely, complete the functional decomposition or the process model first.

Description

Rows, columns, cells

The rows are the functions the solution performs. They are harvested from the functional decomposition, the process model and the existing use cases, which is what guarantees that no function is missed and that each one sits in a real scenario. Granularity is the only genuine judgement on this axis: a row per screen is too fine, a row per module too coarse. The workable unit is an action a user can be permitted or refused, which usually corresponds to a use case or a user story.

Two writing conventions coexist, and confusing them produces an incoherent grid. BABOK marks its cells with a cross: the row there is a complete activity, "create new account", "view reports", and the cell says only permitted or not permitted. Practice tends to write the verbs create, read, update and delete instead, which the guide itself places at the information system level, in the CRUD matrix. With the verbs, the row becomes the object they bear on, the file, the invoice, the parameter, and the letters supply the actions. One grid holds one convention or the other, never both, or its cells change meaning from row to row.

The columns are the roles. They are derived from organisational models, job descriptions, procedure manuals and system user guides, then completed in working sessions with each business area, because documents describe the organisation as it was decided, while the sessions show how it works. The grouping criterion is the community of functions performed: two separate reporting lines can hold the same role. Non-human roles are columns in their own right: interfaces with partner systems, batch jobs, technical accounts, software agents. They usually end up with the widest rights in the system, precisely because nobody gave them a column.

The cells carry the authorities. The vocabulary quickly outgrows the four verbs, and every addition matches a real decision: execute for launching a job or producing a report, approve for the workflow decision that carries most of the segregation of duties constraints, export or print for the action that takes data out of the controlled system, which makes it a right distinct from reading, delegate for the authority a holder may pass to another, temporarily or permanently. Scope qualifiers come on top: reading one's own file rather than every file, reading within one's own unit rather than across the company. The guide treats inheritance and delegation explicitly as refinements of the grid, that is, as decisions to be taken.

A role is a label for a group

A role denotes a group of individuals who share common functions. Two people with the same job title may hold different roles; two different job titles may cover the same role. This is the design rule everything else depends on: a column named after the person who happens to hold the post today encodes a career, and it becomes a set of rights nobody can justify the day that person leaves.

The indirection the grid draws is that of role-based access control, formalised by Ferraiolo and Kuhn at NIST in 1992 and standardised as ANSI/INCITS 359. People are assigned to roles, roles are assigned to permissions, and no permission is ever assigned directly to a person. Sandhu, Ferraiolo and Kuhn describe four cumulative levels, each adding exactly one requirement: flat RBAC, where users acquire their permissions through their roles and where one can establish which roles a person holds and which people hold a role; hierarchical RBAC, which allows inheritance between roles; constrained RBAC, which adds separation of duty constraints; symmetric RBAC, which adds the reverse review, establishing for a given permission which roles hold it. That last level is the one every auditor asks for. It is also the most rarely reached.

Filling the grid

1. Fix the boundary and the level of abstraction
   System functions or process activities, never both in one grid. Level of detail is the limitation the guide itself acknowledges for this technique.
2. Harvest the functions
   From the functional decomposition, the process model and the use cases. If none of those artefacts exists, the technique is premature.
3. Derive the roles
   From the organisational documents, then hold a short session per business area to find the missing roles and merge the duplicates. Write each role's one-line definition immediately.
4. Fill row by row
   Never column by column: reading by row forces the question "who else touches this function", which is how forgotten roles surface, something the guide counts among the very purposes of the technique.
5. Run both rules over the filled grid
   Least privilege: can this role do its job without this authority. Segregation of duties: does any role both initiate and approve the same transaction. Both rules produce changes to cells.
6. Have it reviewed separately by the business and by audit
   The business owner confirms the work remains doable, internal audit and the data protection adviser confirm it cannot be abused. The two reviews find different defects.
7. Reconcile with reality
   If the system exists, extract the entitlements actually granted and compare them with the grid. The differences are either defects in the matrix or unauthorised access.
8. Set the maintenance cadence before closing
   A named owner per role, a recertification interval and the trigger events, joiner, mover, leaver, new function delivered.

Least privilege and segregation of duties

Least privilege comes from Saltzer and Schroeder, whose 1975 formulation still holds: "Every program and every user of the system should operate using the least set of privileges necessary to complete the job." The same paper gives separation of privilege, under which a protection mechanism requiring two keys is more robust than one that opens to a single key. NIST supplies the operational version in the AC family of SP 800-53: each entity is granted the minimum resources and authorisations it needs to perform its function. In Swiss law this engineering rule has become an obligation, in art. 3 para. 1 let. a DPO.

Segregation of duties forbids any single user from holding enough privileges to misuse the system alone, the canonical example being that whoever authorises a salary must not be able to prepare it. It is enforced statically, through mutually exclusive roles one person cannot combine, or dynamically, through a two-person rule at the moment of the transaction. SP 800-192 states the constraint the grid has to express: if one role requests an expenditure and another approves it, the organisation may prohibit assigning both roles to the same user. That constraint cannot be drawn on a two-axis grid, which is why the constraints list is a piece of the deliverable.

Logging is the counterpart of refusal. Swiss law regulates it. Where sensitive personal data is processed by automated means on a large scale or high-risk profiling is carried out, and where preventive measures are unable to guarantee data protection, art. 4 DPO requires logging at least the storage, alteration, reading, disclosure, deletion and destruction of the data. Reading is therefore a logged event, which makes a read cell a security decision in its own right. The same threshold triggers a processing policy (art. 5), to which the matrix is the natural annex. On the certification side, the controls the auditor will name are those of Annex A to ISO/IEC 27001:2022: 5.15 access control, 5.16 identity management, 5.18 access rights, 8.2 privileged access rights, 5.3 segregation of duties, which is this same rule under the name the standard gives it.

From cell to requirement

Every non-empty cell is rewritten as one testable sentence: role R holds authority A over function or object O, within scope S. That sentence enters the requirements set, traces back to the use case it came from and generates two test cases: the positive one, where the role succeeds, and the negative one, where every other role fails. The second is the one teams skip. It is nonetheless the only one that demonstrates that access control works: a system that permits correctly and refuses badly passes every functional test.

Inheritance and delegation are written outside the grid, in a fixed form. An inheritance rule takes one line of the constraints list: the authority concerned, the hierarchical level it applies from, the subordinate units it reaches. A delegation takes another: the delegable authority, the role that holds it, the role or scope that may receive it, the duration, the event that revokes it. Each generates its own negative test, the one checking that a team leader does not inherit an authority the grid refuses to the team, the one checking that an expired delegation leaves no right behind.

Alongside the cells, the grid generates administration requirements that get forgotten because they are written nowhere in the table: who assigns a role, what approval that assignment requires, how often assignments are recertified, how they are revoked and what happens on an internal transfer. Those requirements decide whether the matrix is still true six months after go-live.

The boundary with the two other matrices

Three grids resemble each other and get confused in the field: this one, the RACI matrix and the CRUD completeness matrix. What separates them is the meaning of a cell. The reason RACI cannot be folded into this one is that consulted and informed are communication states between people: a function cannot be consulted, and a system cannot enforce those two letters.

The pitfalls

Role explosion

One role per combination of permissions. The symptom is visible: more roles than job families, roles that differ by a single cell, names carrying a qualifier such as Handler_VD_read_only. The cause is constant, encoding context, scope, threshold or ownership in the role name. Kuhn, Coyne and Weil put a number on the limit: implementing n attribute conditions in a role model can require up to 2ⁿ roles, and RBAC supports dynamic attributes such as time of day poorly. Their conclusion is the trade to remember: a role model exchanges up-front structuring effort for easy administration and review, the attribute approach makes the reverse trade, easy to set up and painful to analyse. The matrix remains the right artefact for the stable layer, the one made of job families; the contextual layer is written as rules, and the two coexist.

The matrix never replayed

Written during the project, accurate on go-live day, never reopened afterwards. Nothing decays faster: every release brings new functions, and each arrives with no row.

Accumulated rights

The same drift compounds through accumulation. A departure is visible and gets handled; the internal transfer is silent, because it adds the new role without removing the old one. After three moves, one person holds a combination nobody ever approved, which breaks segregation of duties.

The gap between the matrix and the entitlements actually granted

The matrix is a requirement, the system's entitlement table is a fact, and the two diverge from the first emergency access granted on a Friday evening. Without periodic reconciliation the document becomes decoration, more dangerous than nothing since it will be shown to an auditor as evidence.

Empty cells with no legend

A blank read as "not decided yet" by the analyst and as "no access" by the developer or the other way round. One sentence in the legend plus a platform that denies by default closes the question.

Function-level access confused with data-level access

Being able to open the invoice screen and being able to see the amounts on every invoice are two distinct rights, and a grid that stops at the screen leaves the second to the developer's judgement.

Implicit inheritance

Does a team leader automatically hold everything the team holds. As long as the answer is unwritten it is taken by default, and it doubles the rights of an entire reporting line.

The role with no named owner

The recertification campaign then has nobody to put the question to, and the answer becomes "approve all". A role without an owner is a role nobody will ever withdraw.

AI considerations

Role mining is the most mature application of AI to this technique. Its failure mode is precise. Clustering algorithms run over existing entitlements propose roles built bottom-up, from what people actually hold. That is a useful counter-check on the matrix built top-down, where the differences are the findings. Used as the starting point, the same technique launders the excess rights that already exist: what people hold today becomes the official definition of tomorrow's role. Mine to contradict the grid, never to produce it.

A language model drafts the grid; it answers for no cell. Fed the use cases and the role list, it produces a complete, plausible matrix in seconds, and a plausible wrong permission is a vulnerability that ships. The economics are unusual: filling in was never the expensive part, and the review, a named business owner confirming each row, does not shrink by a minute. The profitable use is twofold, producing the candidate grid and producing the negative test cases, row by row, which are tedious and which nobody writes by hand.

Anomaly detection over entitlements deserves naming separately, because it attacks the real cause of failed recertifications, reviewer fatigue. Peer-group outlier detection, this person holds a permission nobody else in their job family holds, turns a campaign of several hundred lines to rubber-stamp into a review of the twenty that differ.

Software agents raise a design question the matrix has to settle explicitly. An assistant acting on a user's behalf is a subject of the access model, and the grid must say whether it acts with its own permissions or with the delegated permissions of the person who invoked it. The delegation refinement is exactly the right place for that decision. The neighbouring subject is document retrieval: an assistant that indexes a base with a single technical account able to read everything reproduces that account's reach for every user who queries it. Permission filtering has to happen at query time, against the same matrix, or the newest component in the architecture bypasses the access control everything else enforces.

Examples

The concept the grid makes visible is refusal: it writes what a role may not do with the same precision as what it may. The case is the reimbursement processing module of a Swiss health insurer, written in the verb convention, so one row per object handled. Under art. 57 para. 7 LAMal, the médecin-conseil, the insurer's medical adviser, passes on to the competent bodies of the insurer only the information they need to decide whether a service is covered, to set the remuneration, to calculate the risk equalisation or to substantiate a decision. The medical details row translates that restriction into authorities: one column reads, the five others are refused.

Two further rows carry a constraint that is not negotiable. The reimbursement decision separates the handler's C and U from the team leader's approval, so that no role both prepares and approves the same decision. The access log carries a single authority, reading by internal audit, with no update and no deletion for anyone: the logging of reads that the DPO requires on health data processed on a large scale proves nothing if a role can retouch it.

Three constraints of this module cannot be drawn on the grid and belong to the deliverable just as it does.

• Mutually exclusive roles: one person cannot hold Claims handler and Team leader at the same time, otherwise the separation visible on the decision row is reassembled inside a single head.
• The log is written by the system: no role holds C on that row, which is what makes it a control.
• A refusal bears on a function, the right of access remains whole: the insured person does not read the medical details in the portal, and their right of access to data concerning them is exercised through the procedure the FADP provides.

Visualisations

The deliverable is a workable table. The real use of the artefact lies in its two reading directions: the row to prepare a requirement, "who touches this function", the column to prepare a role assignment, "here is everything this role holds". A picture of a grid loses both, along with the sorting, the filtering and the formula checks that give the artefact its maintenance value.

Four conventions separate a workable grid from a drawing. The legend defines every letter for this system, including the letter of refusal. The refusal is written, with a visible mark, since an empty box reads two ways. Scope sits inside the cell, because an authority limited to one's own file is a different authority. Approval is visually distinct from the write verbs, because it is the one an eye scans to check segregation of duties.

Cost

The dominant cost is the recurring review. Recertifying assignments and reopening the grid at every release that adds a function outweighs, over the life of the solution, everything the initial build cost. A matrix budgeted as a project deliverable is a matrix that will stop being true.

Tooling

The spreadsheet remains the right tool for the analysis artefact, for longer than one expects: up to some fifteen roles and sixty functions, with conditional formatting that surfaces the rows holding no authority and the roles holding everything. Beyond that it stops being read. Where the matrix must live beside the requirements it traces to and carry a change history, it belongs in the requirements tool or the team's collaboration space, Confluence, Jira or Azure DevOps.

Modelling workbenches change the nature of the object. Where roles, functions and data objects already exist as model elements, the matrix views of Sparx Enterprise Architect or the ArchiMate access relationships in Archi produce the grid as a view over the model, which follows every change to it.

The target platform deserves to be opened before the row granularity is frozen, because its smallest assignable unit is the real floor for a row: Microsoft Entra ID roles and groups, Salesforce profiles and permission sets, SAP roles and authorisation objects, ServiceNow access control lists, Keycloak, Okta. A grid finer than the platform produces requirements no configuration can satisfy.

Identity governance platforms, SailPoint, Saviynt, Omada, One Identity or Microsoft Entra ID Governance, serve the moment when access has to be proven correct: recertification campaigns, segregation of duties rule engines, joiner mover leaver automation and the entitlement extract that gets compared with the matrix. Their cost is justified as soon as that comparison is manual and annual. Their role mining features serve the counter-check, never the build. When rules become contextual, a policy engine, Open Policy Agent with Rego, AWS Cedar or an XACML implementation, carries the layer the grid cannot, while the grid keeps the stable roles. Finally, where a catalogue of segregation of duties conflicts already exists for the business processes, the access control suites of enterprise resource planning packages, SAP GRC Access Control and its equivalents, save deriving it again by hand.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.39 Roles and Permissions Matrix: the definition of a role as a label for a group sharing common functions, the figure whose cells carry a cross, the three elements (identifying roles, identifying activities, identifying authorities), the refinements that are delegation and inheritance, the sources rows and columns are derived from and the acknowledged limitation on level of detail.
• Ferraiolo, D. F. and Kuhn, D. R., Role-Based Access Controls, 15th National Computer Security Conference, NIST, 1992: the founding paper of role-based access control and of the indirection between users, roles and permissions.
• Sandhu, R., Ferraiolo, D. and Kuhn, R., The NIST Model for Role-Based Access Control: Towards a Unified Standard, 5th ACM Workshop on Role-Based Access Control, 2000: the four cumulative levels, flat, hierarchical, constrained and symmetric, each adding exactly one requirement.
• NIST, Role Based Access Control (project page): the standardisation of the model as ANSI/INCITS 359-2004, revised as INCITS 359-2012.
• Saltzer, J. H. and Schroeder, M. D., The Protection of Information in Computer Systems, Proceedings of the IEEE 63(9), 1975: the primary source of least privilege and separation of privilege.
• Kuhn, D. R., Coyne, E. J. and Weil, T. R., Adding Attributes to Role-Based Access Control, IEEE Computer 43(6), 2010, pp. 79-81: role explosion, the 2ⁿ roles bound for n attribute conditions and the trade-off between a role model and an attribute model.
• NIST, SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations: the definition of attribute-based access control, for the contextual layer the grid does not carry.
• NIST, SP 800-192, Verification and Test Methods for Access Control Policies/Models: separation of duty as a formal constraint, static or dynamic, expressed over mutually exclusive roles.
• NIST, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, AC family: least privilege and separation of duties as enforceable, verifiable controls.
• ISO/IEC, ISO/IEC 27001:2022, Annex A: controls 5.15 access control, 5.16 identity management, 5.18 access rights, 8.2 privileged access rights and 5.3 segregation of duties, cited by designation.
• Swiss Confederation, Federal Act on Data Protection (FADP), SR 235.1: art. 7, data protection by design, and art. 8, data security through appropriate technical and organisational measures.
• Swiss Confederation, Ordinance on Data Protection (DPO), SR 235.11: art. 2 objectives, art. 3 para. 1 let. a data access control, art. 4 logging including reading, art. 5 processing policy.
• Swiss Confederation, Federal Act on Health Insurance (LAMal/KVG), SR 832.10: art. 57 para. 7, the only information the médecin-conseil passes on to the competent bodies of the insurer.