A People & Accounts register does not replace your HRIS, MDM, directory, identity provider, or spreadsheets. It fills the evidence gap those tools leave behind: who exists, which systems or accounts they hold, who owns each account, what status the account is in, and when the record was reviewed. HRIS answers employment questions. MDM answers device-management questions. Directories and identity providers answer authentication questions for connected systems. Spreadsheets answer whatever someone remembered to type. CertPilot's People & Accounts register answers the governance question leadership and reviewers keep asking: who has access to what, and can we show it clearly?
Jordan usually feels this difference during offboarding. HR says the employee left last Friday. MDM shows the laptop was wiped. The identity provider shows one set of connected applications. A spreadsheet has an old tab with system names, but nobody knows whether it is current. Then the CFO asks, “Can we prove their accounts were handled?” None of the adjacent systems is wrong. They are just incomplete for this job.
The mistake is treating adjacent records as proof. A person existing in HRIS is not an account inventory. A managed device is not access ownership. A directory account is not every SaaS login. A spreadsheet row is not a dated review routine. A People & Accounts register brings those scattered views into a customer-maintained evidence record that can feed access reviews, offboarding follow-up, and evidence reports.
The plain-English split
Use this mental model.
An HRIS is about employment. It tells you who works here, their department, their manager, their start date, and their termination date. It is upstream of access, but it is not the access map.
An MDM is about devices. It can enrol, configure, secure, wipe, and enforce controls on laptops or phones. It may tie a device to a user, but it is not a record of every account the person holds.
A directory or identity provider is about authentication and authorization for connected systems. It can be powerful, but it only sees what is connected and modeled. It does not automatically know every shared login, local admin account, vendor portal, client tool, niche SaaS account, or system outside SSO.
A spreadsheet is about flexibility. It can hold a first draft of anything. It is also easy to fork, forget, and leave undated.
A People & Accounts register is about governance evidence. It records the people-to-account mapping in a way a small team can maintain, review, import, export, and use during access reviews.
Why this matters in lean IT
Large companies often solve the access-evidence problem with enterprise IAM, IGA, HR integrations, directory governance, formal ticketing, and compliance teams. Lean teams rarely have that machinery. They have a few trusted systems, a lot of exceptions, and one person expected to explain the whole picture.
That is why “we already have HRIS” or “we already have MDM” does not settle the question. The access evidence problem lives between systems. It is the gap between HR knowing a person left, IT knowing a device was handled, managers knowing the person should or should not still have access, and nobody holding a single dated record of the account outcome.
The register is not glamorous. It is the shared notebook that becomes trustworthy because it has structure: person, account, system, owner, status, dates, and notes. The structure is what turns a list into evidence.
What an HRIS can and cannot prove
An HRIS is the right source for employment facts. It can usually prove that a person joined, changed role, changed manager, or left. It can provide the people list that starts a register. It can help scope an access review by identifying active employees, contractors, and leavers.
What it cannot prove by itself is account handling. It does not know that a marketing contractor still has a login to an analytics tool. It does not know that a former finance employee still appears in a supplier portal. It does not know that a shared admin account is informally held by two people. It records the employment event, not every system affected by that event.
Treat the HRIS as the people source. Then add the account layer somewhere else. That somewhere else can begin as a spreadsheet, but it needs owner, status, and review discipline if it is going to support access review evidence.
What an MDM can and cannot prove
An MDM is a control tool for devices. If a laptop is lost, an MDM may enforce policy, lock it, wipe it, or show it as managed. That is valuable and it is not a register’s job. The asset-side comparison is covered in IT asset register vs IT asset management.
But device control is not access ownership. A person can use a cloud account from another browser. A vendor portal may have no device dependency. A shared account may sit outside the managed endpoint flow. Even if every laptop is controlled, you still need to know which people and accounts exist across systems.
A People & Accounts register should never pretend to wipe or manage devices. Its value is different: it preserves the people-to-account record that MDM does not hold.
What a directory or identity provider can and cannot prove
A directory or identity provider is closer to the access problem, but it is still not the whole answer. It can show identities, groups, SSO applications, and sometimes provisioning status for connected apps. For connected systems, it can be a strong evidence source.
The blind spot is scope. Many lean teams have systems outside SSO: admin consoles, vendor portals, client platforms, legacy tools, shared logins, local accounts, contractor accounts, and one-off SaaS products. Some accounts belong to systems that were set up before the IdP was adopted. Some access exists by invitation rather than central provisioning. The article on SSO blind spots covers that problem in more depth.
A register should not compete with the identity provider. It should complement it by holding the full review scope: connected systems, disconnected systems, exceptions, and owner notes.
What spreadsheets can and cannot prove
A spreadsheet is often the first honest version of the register. That is fine. A CSV-friendly register exists because the first people-and-account map usually starts in a spreadsheet.
The weakness is not the grid. The weakness is governance. A spreadsheet becomes weak evidence when no one owns it, rows have no review date, statuses are inconsistent, old tabs fork into new copies, and the team cannot tell whether the list is current. A spreadsheet can hold data, but it does not create a review routine by itself.
If the spreadsheet is still useful, import it, preserve what is true, and add the missing discipline. The comparison between reports, dashboards, and spreadsheets is covered in evidence reports vs dashboards vs spreadsheets.
What the People & Accounts register should hold
A useful register does not need to become HR software. It needs the fields that make access ownership reviewable.
For people, record name, work email, department, role or title, person type, status, start date, end date where relevant, and notes. For accounts, record system, account identifier, account status, owner or responsible person, account creation or review date, status-change date, and notes. For shared or service accounts, make ownership explicit rather than pretending a non-human account can own itself.
The field-level version is in what to track in a manual accounts register. The ownership version is in account ownership tracking.
The access review connection
The register is not the review. It is the input.
An access review asks whether the current people-to-system access still makes sense. The register gives the review a starting scope: people, systems, account identifiers, account status, and owners. The Access Reviews workflow then records decisions, action-required items, and completion evidence. The relationship is covered in how a People & Accounts register supports access reviews.
This distinction prevents overclaiming. A register does not automatically remove access. It does not prove every permission is correct. It gives reviewers a maintained picture they can work from, then records what they decided.
A practical offboarding example
Suppose Priya leaves the company.
The HRIS confirms her end date. The MDM confirms her laptop was returned or wiped. The identity provider shows her central account was disabled. The register shows the rest: which SaaS tools, vendor portals, shared accounts, admin consoles, and client systems had a Priya-owned or Priya-used account; who confirmed each item; and which accounts were removed, transferred, retained for business reason, or still need follow-up.
That last record is what leadership, insurance, or an audit-adjacent review is really asking for. It is the evidence behind the employee offboarding checklist. Without it, the answer is scattered across systems and people.
How to layer the tools without duplicating everything
Do not copy every HR field into the register. Do not copy every device field from MDM. Do not copy every group from the directory. Keep only the fields that help the access evidence job.
A clean layering pattern looks like this:
- HRIS remains the employment source.
- MDM remains the device control source.
- Directory or IdP remains the authentication source for connected systems.
- Spreadsheet remains useful for temporary bulk cleanup or import/export.
- People & Accounts register becomes the reviewable account-evidence layer.
- Access Reviews becomes the decision and completion layer.
- Evidence Reports become the management-facing artifact.
Each layer keeps its job. That is how a lean team avoids both under-proving and overbuying.
What not to claim
Do not claim the register finds accounts on its own. It does not. Do not claim it syncs from Google Workspace, Microsoft 365, HRIS, MDM, directories, or SaaS admin systems unless that connector actually exists. Do not claim it deprovisions users, revokes access, runs HR, manages devices, watches employees, reads private content, or provides compliance certification.
The honest claim is stronger: the register gives the team a maintained, reviewable record of people and accounts, so access reviews and offboarding evidence do not depend on memory.
How CertPilot fits today
CertPilot’s People & Accounts register is manual-first. Teams add records manually or import CSV files. It tracks people, roles, departments, statuses, account identifiers, account status, status-change dates, notes, and an accounts matrix view. It supports CSV import and export, and it connects naturally to Access Reviews and the cross-module Evidence Reports surface.
People & Accounts does not generate a People-specific PDF report today. In the Governance Evidence Pack, People & Accounts appears as summary counts where specified. For access-specific evidence, the live report surface is the Access Review Register PDF.
A 30-day first pass
Week one: export the HR people list and identify active employees, contractors, leavers, and unknowns. Do not overbuild the register; get the people scope right.
Week two: add accounts for the highest-risk systems first: finance, payroll, admin consoles, identity provider, hosting, customer systems, production tools, and shared service accounts.
Week three: name an owner for every account. Shared and service accounts need human owners. Blank owner fields become the work queue.
Week four: run a first access review using the register, complete the review, record actions, and produce a management summary. If scope is incomplete, say that. Honest scope is more credible than fake completeness.
The comparison packet Jordan should keep
When the same debate returns next quarter, Jordan should not rebuild the explanation from scratch. Keep a short comparison packet that explains the boundary between systems in operational language.
The packet should start with the current evidence question. For example: “Can we show which people have accounts on important systems and whether leavers were handled?” That sentence keeps the comparison anchored. The question is not “which tool stores people?” or “which tool has the most features?” It is “which tool produces the evidence we need?”
Then list the sources the team already trusts. HRIS provides employment status. MDM provides device state. The identity provider provides connected identity and group information. Existing spreadsheets provide partial account lists. Managers provide business context. System owners provide whether access is still appropriate. The People & Accounts register is where those pieces become a reviewable account record.
Next, record the boundaries explicitly. The HRIS is authoritative for employment but not account ownership. MDM controls devices but not SaaS access. The identity provider is powerful but only covers connected scope. A spreadsheet is flexible but weak unless someone owns status and review dates. The register is customer-maintained; it does not discover accounts or remove access.
Finally, keep a first-scope decision. Choose the first ten or twenty systems that matter most: finance, payroll, email, identity, production, hosting, customer data, admin consoles, and core vendors. Add disconnected systems as they are found. The point is to build trust through honest scope, not to imply instant whole-company completeness.
This packet gives Jordan a repeatable answer when leadership says, “Don’t we already have this in HR?” The answer becomes: “HR gives us the people source. The register gives us the account-evidence layer. Access Reviews records the decision. Reports make it readable.”
A maintenance rule that keeps the register trusted
The register only stays useful if updates follow a trigger. Add or update records when someone joins, leaves, changes role, gains a privileged account, loses a privileged account, becomes a vendor contact, or owns a shared account. Then run a short monthly cleanup for stale statuses and blank owners.
This avoids the usual spreadsheet decay. The register is not “kept current” by hope; it is kept current by tying updates to business events. Jordan should be able to say when the register changes and who is responsible for the next cleanup pass.
In short
- HRIS records employment; it does not map every system account.
- MDM manages devices; it does not prove cloud access ownership.
- Directories and IdPs cover connected identity; they do not automatically cover every system.
- Spreadsheets are useful starts but weak evidence without ownership, status, and review discipline.
- A People & Accounts register is the customer-maintained evidence layer that feeds access reviews and management reporting.
Frequently Asked Questions
Does a People & Accounts register replace my HRIS?
No. The HRIS remains the employment system of record. The register uses people context to track system accounts, ownership, statuses, and review evidence. The HRIS tells you who works here; the register helps show what access they hold.
Is a People & Accounts register an MDM?
No. MDM manages devices and can enforce controls on them. A People & Accounts register records people and account evidence. It does not manage, wipe, monitor, or control devices.
If I already have Google Workspace, Microsoft 365, Okta, Entra, or another IdP, do I still need a register?
Often yes, because the identity platform only covers what is connected and modeled. A register helps capture disconnected systems, exceptions, shared accounts, vendor portals, and manual review context. CertPilot does not currently sync from those systems.
Can I just use a spreadsheet?
You can start with a spreadsheet. The risk is drift: no owner, no date, inconsistent status labels, and copied tabs. A register keeps the same data reviewable with ownership, status, dates, import/export, and access-review connection.
Does CertPilot find accounts on its own or remove access?
No. CertPilot is customer-maintained today. It does not discover accounts automatically, sync directories, or remove access. It records the people-and-account picture and supports review evidence; changes happen in the underlying systems.