How to Build a User-System Access Matrix Without an IAM Connector

You can build a useful user-system access matrix without an IAM connector by starting with known systems, known people, and known accounts — then recording one reviewable row per person-system relationship. The goal is not perfect automatic discovery. The goal is a maintained, dated matrix that answers: who has access, to which system, at what level, who owns the system, when it was last reviewed, and what action is needed.

That distinction matters. A manual matrix will not find every hidden account or calculate every effective permission. But for lean IT teams, it can replace scattered spreadsheets and memory with an operational register that produces access-review evidence.

What a user-system access matrix is

A user-system access matrix is a structured view of people against systems. Each cell or row records the access relationship between one person and one system: no access, read-only, standard user, admin, owner, custom role, or action required.

A simple matrix answers five questions:

• Which people are in scope?
• Which systems are in scope?
• What access does each person have?
• Who can confirm whether that access is appropriate?
• When was the access last reviewed?

In CertPilot’s Access Reviews, the Systems Catalog defines the systems and the review matrix lets you record the person-system access level. The same structure can start in a spreadsheet if you are not using a dedicated tool yet.

When you need a manual matrix

A manual access matrix is most useful when your access data is fragmented. Common situations:

• some SaaS tools support SSO and some do not;
• smaller vendor portals use local accounts;
• finance, hosting, CRM, admin consoles, and support tools each export different fields;
• contractors, vendors, shared accounts, and service accounts do not map neatly to a single HR list;
• the company is too small for enterprise identity governance, but still gets access-review questions;
• leadership or an auditor asks who has access and the answer is spread across several systems.

If you already run a mature identity-governance tool, use that as the source of truth. If you do not, a manual matrix is often the first honest step.

Step 1: Define the systems in scope

Do not begin with people. Begin with systems. The access question is always “access to what?”

Create one system record for each app, platform, portal, or admin surface that matters. Start with the places where stale access would create business risk:

• email and identity administration;
• finance and payroll;
• CRM and customer data;
• code hosting and production admin tools;
• support desks and customer portals;
• cloud hosting and DNS/domain systems;
• HR, recruiting, and contractor systems;
• key vendor portals and external admin consoles.

For each system, record:

• system name;
• purpose;
• business owner;
• technical owner;
• criticality;
• lifecycle status;
• whether it should appear in access reviews.

This is where the Systems Catalog matters. A matrix with unnamed or unowned systems quickly becomes another spreadsheet nobody trusts.

Step 2: Define the people and account population

Next, create the people list. At minimum, include:

• full name;
• work email or account identifier;
• department or team;
• role or title;
• person type, such as employee, contractor, vendor, or service account owner;
• status, such as active, offboarding, left, suspended, or unknown;
• manager or accountable owner where useful.

If the person/account source is messy, do not wait for perfection. Start with the best available HR export, payroll list, people spreadsheet, or People & Accounts register. Mark uncertainty explicitly. A row with “status unknown” is more useful than an invisible person.

For shared and service accounts, do not force them to look like employees. Record the accountable owner and purpose. During a review, the question becomes “is this shared/service account still needed and who owns it?” rather than “which employee is this?”

Step 3: Normalize access levels

Raw permission names are often too vendor-specific for a reviewer. One system says “Global Admin,” another says “Owner,” another says “Billing Manager,” and a small SaaS tool just says “User.” Keep the original role if you need it, but normalize into a small decision-friendly set.

A practical access-level set:

• No access — person should not or does not have an account.
• Read / view — can see information but not change core records.
• Write / edit — can create or update normal records.
• Admin / manage — can configure the system or manage users.
• Owner — accountable for the system or highest-level access.
• Custom — vendor-specific access that needs a note.
• Unknown — access exists but the level has not been interpreted yet.

This is not a permission model. It is a review model. The purpose is to let a manager or system owner make a decision without decoding every vendor’s internal language from scratch.

Step 4: Create one row per person-system relationship

For each person-system pair you know about, record a row. The row should include:

• person name;
• account identifier;
• system name;
• access level;
• original role or group name if useful;
• system owner or reviewer;
• current status;
• review result;
• action-required note;
• last reviewed date;
• next due date;
• evidence note.

Do not create rows for every possible blank cell unless your team can maintain that volume. Start with known access and known no-access exceptions, then expand. The first matrix is allowed to be incomplete as long as it is honest.

Step 5: Add evidence notes, not just decisions

A matrix with only “approved” or “remove” is weak. A reviewer later needs to know why the decision was made.

Good evidence notes are plain and short:

• “Sales Ops confirmed read-only CRM access still needed for renewal reporting.”
• “Former contractor account found in vendor portal; removal requested in ticket IT-482.”
• “Admin role downgraded to standard user in finance app after owner review.”
• “Role name unclear in vendor export; system owner to confirm before sign-off.”

The note should not contain secrets, passwords, private HR detail, or unnecessary personal information. It should explain the access decision and follow-up.

Step 6: Review by system, not by spreadsheet row

The fastest way to create rubber-stamping is to send a giant matrix to a manager and ask them to approve it all. Better pattern:

1. Group the matrix by system.
2. Give the system owner the people and access levels for that system.
3. Ask whether each person still needs that level.
4. Record keep, change, remove, no access, or action required.
5. Make operational changes in the underlying system.
6. Update the matrix after the change.

This is why the split between manager and system owner matters. A manager knows whether the person still belongs; the system owner knows whether the permission level is right.

Step 7: Complete the review and export the artifact

Once the matrix has been reviewed, complete the access review. The completion event should record:

• who completed the review;
• completion date;
• review period;
• cadence;
• next due date;
• number of people reviewed;
• number of systems reviewed;
• number of access records reviewed;
• open action-required count;
• evidence note.

Then export the Access Review Register PDF or equivalent artifact. This turns the matrix from an internal working file into management-ready evidence.

What this matrix does not do

A manual matrix has limits, and you should state them clearly:

• It does not discover accounts automatically.
• It does not connect to Google Workspace, Microsoft 365, Entra, HRIS, or SaaS admin APIs.
• It does not calculate effective permissions across nested groups.
• It does not remove or change access.
• It does not prove every possible account exists.
• It does not certify compliance or guarantee audit outcomes.

Those limits do not make the matrix useless. They make it honest. The matrix is the customer-maintained evidence layer for known systems and known access.

How CertPilot fits

CertPilot gives lean teams a place to maintain this matrix without pretending it is an IAM platform:

• the People & Accounts register records who exists and which accounts are known;
• the Systems Catalog records systems, owners, criticality, and whether each system appears in access reviews;
• Access Reviews records access levels, review results, action-required notes, due dates, and completion evidence;
• the Access Review Register PDF shows the finished evidence pattern in the sample reports gallery.

CertPilot does not sync directories or remove access. You enter or import the data, review it, complete the review, and keep the evidence.

A starter template

Use this field set for the first pass:

• Person name
• Account email or identifier
• Person status
• System name
• System owner
• System criticality
• Access level
• Original role/group name
• Review result
• Action required
• Last reviewed date
• Next due date
• Evidence note

That is enough to answer “who has access to what?” and to run the first quarterly access review. You can add more fields later, but do not let a perfect model delay the first maintained register.

In short

• A user-system access matrix maps people to systems and records the access level, owner, status, review decision, and evidence note.
• Start with systems, then people, then access levels; do not begin with a blank spreadsheet of every possible permission.
• Normalize raw roles into decision-friendly levels so reviewers can judge access without decoding every vendor export.
• Complete the review and export the artifact so the matrix becomes evidence.
• CertPilot supports manual-first records, CSV import/export, review decisions, completion evidence, and PDFs; it does not discover accounts or act inside your systems.

Frequently Asked Questions

Can I build an access matrix without SSO or IAM?

Yes. Use known systems, known people, known accounts, CSV exports, and manual owner input. It will not be a complete automatic inventory, but it can be a reliable review register if you keep scope and limitations clear.

Should the matrix be person-based or system-based?

Maintain it as person-system records, but review it by system. System owners are usually best placed to judge whether the access level is correct.

What if I do not know the access level?

Record it as unknown and assign follow-up. Unknown is better than guessing. The review should surface ambiguity rather than hide it.

Does CertPilot replace an IAM or IGA tool?

No. CertPilot is a manual-first evidence and review workflow. It records access data and review decisions; it does not enforce policies, sync directories, or remove access.

How often should I update the matrix?

Update it whenever people join, leave, change roles, or when important systems change. Then review it on a fixed cadence, commonly quarterly, so each cycle creates dated evidence.