Jordan did not lose control of access in one dramatic event. It happened one exception at a time. A contractor kept a project-management login after the contract ended. A shared mailbox had no named owner. A finance SaaS account used a personal email because it was set up in a rush. Then a manager asked for a list of who had access to which systems, and the spreadsheet looked busy but not review-ready.
A manual accounts register should track two connected things: people and accounts. Per person, keep name, work email, department, role, type, status, start date, end date, and notes. Per account, keep system, account identifier, account status, created date, status changed date, and notes. The owner of the account should be the person record it is attached to. Those fields turn a flat login list into access evidence, and CertPilot's People & Accounts register is built around that manual-first field set.
This is the field-level setup guide. For the concept, start with what a People & Accounts register is. For how it supports reviews, read how a People & Accounts register supports access reviews. When the immediate risk is a leaver or contractor account that may still be active, use the former employee accounts checklist. This article goes straight into the fields and the habits that keep them useful.
The short answer
Track a person layer and an account layer.
The person layer should answer:
- Who is the person?
- What team or role gives context to their access?
- Are they active, offboarding, or left?
- When did they start or leave?
- Is there a note that helps IT interpret ownership without storing HR-sensitive detail?
The account layer should answer:
- Which system is the account on?
- What identifier names the account inside that system?
- Which person owns or is accountable for it?
- Is the account active, disabled, deleted, or pending removal?
- When was it created and when did the status last change?
- What exception note explains anything unusual?
If those fields are present and filled consistently, the register can support offboarding, access reviews, ownership questions, and management evidence. If those fields are missing, the register is just another spreadsheet that looks full but cannot answer the question.
Why manual account evidence gets messy
Without connectors, account data is assembled by hand. That is fine. Manual-first can work when the field set is small and consistent. The failure mode is uncontrolled vocabulary.
One person writes "active." Another writes "yes." Someone else leaves the status blank because the account probably exists. Systems get named three ways: "M365," "Office," and "Microsoft 365." Contractors are tracked in a side tab. Shared accounts are written as comments instead of rows. Six months later, nobody trusts the list enough to run an access review from it.
The fix is not more columns. The fix is a small set of fields with consistent meanings. A register with twelve well-maintained fields beats a forty-column spreadsheet that nobody fills in.
Person fields to track
A person record is the anchor for account ownership. Keep it lean.
Full name
Use the person’s normal working name. This is the minimum human-readable identifier. Avoid overloading it with department, location, or status.
Work email
Use the work identity when one exists. It helps match exported account lists and makes duplicate people easier to spot.
Department and role
Department and role explain why access may be appropriate. A finance-system account attached to Finance is different from the same account attached to a marketing contractor.
Person type
Use a simple type set such as employee, contractor, vendor, service owner, or other. Contractors and vendor users are where registers often fail, so this field earns its place.
Person status
Use status values that drive action:
- active;
- offboarding;
- left;
- inactive or needs review.
The offboarding and left statuses matter because they expose accounts that should be reviewed. For the end-to-end evidence flow, see the employee offboarding evidence checklist.
Start and end dates
Dates turn the register from a list into evidence. A person marked left with no end date creates a weak record. A person marked left on a specific date lets IT ask whether accounts were disabled on time.
Person notes
Use notes sparingly. Good notes explain ownership context: "contractor managed by Product," "vendor admin for payroll implementation," or "shared mailbox owner." Bad notes store HR detail, disputes, performance information, or anything a people system should own instead.
Account fields to track
Each account row should attach to one person or accountable owner. If the account is shared or service-like, attach it to the responsible person and explain the shared nature in notes.
System
The system is the application, platform, mailbox, admin console, or service where the account lives. Use one canonical name per system. Pick "Microsoft 365" or "M365," not both. Pick "GitHub" or "GitHub Enterprise," not a rotating mix.
The system name should align with your Access Reviews systems catalog where possible. If the access review matrix uses one label and the account register uses another, reconciliation becomes manual again.
Account identifier
This is the username, email address, login name, mailbox, or service-account identifier. It must be specific enough that a reviewer can find the account in the underlying system.
Examples:
- jordan@example.test;
- finance.shared@example.test;
- svc-deploy-prod;
- github:jordan;
- slack:U12345 if the exported system uses IDs.
Do not store passwords, recovery codes, API tokens, private keys, or full secrets in the identifier or note fields.
Account owner
In the register, account owner should usually be the linked person. For shared accounts and service accounts, the owner is the accountable human, not every user who touches it. Account ownership tracking covers that distinction in more detail.
Account status
Use action-oriented statuses:
- active;
- disabled;
- deleted;
- pending removal;
- needs review.
A status of disabled or deleted is a record that an action happened in the underlying system. The register does not disable or delete accounts. It records what your team did elsewhere.
Created date and status changed date
The created date helps answer how long an account has existed. The status changed date is more important for evidence. It shows when the team disabled, deleted, marked pending removal, or confirmed active status.
For leavers, the useful comparison is person end date versus account status changed date. That tells you whether account cleanup happened promptly or drifted.
Account notes
Use account notes for exceptions:
- shared support mailbox;
- service account owned by Infrastructure;
- temporary vendor admin until migration ends;
- pending removal after finance approval;
- account exists outside SSO and needs manual review.
The note should explain the exception without becoming a dumping ground.
System and vendor context
An account register is not a renewal register, but the systems overlap. The account row says who has access to a system. The Renewals & Vendor Register says who owns the commercial relationship, renewal date, notice deadline, and decision context. The Assets Register says what hardware and software records exist. Keep each fact in the right place.
Use system names consistently across those registers when possible. If the account register says "Figma," the renewal register says "Figma Enterprise," and the access review says "Design Tool," the same system becomes three different workstreams. A small naming convention avoids a lot of later reconciliation.
Review-ready field rules
A manual accounts register is review-ready when each row can be used without reconstruction.
A person row is review-ready when:
- the person has a name and work email;
- department or role gives context;
- status is current;
- start or end date is filled where relevant;
- notes do not contain sensitive HR detail.
An account row is review-ready when:
- the system name is specific and standardized;
- the account identifier is findable in the actual system;
- the row attaches to a person or accountable owner;
- status is current;
- status changed date is present for disabled, deleted, pending-removal, or recently confirmed accounts;
- notes explain exceptions.
A register that admits "needs review" is better than a register that hides uncertainty. Unknowns are not defects when they are marked and assigned. They become defects when they are invisible.
What not to track
The register earns trust by refusing to become a surveillance or secrets database.
Never track passwords, API keys, private keys, recovery codes, session tokens, or full product keys. A register lists accounts; it must not grant access to them.
Never track sensitive HR data such as payroll, health, performance, disciplinary history, or personal reasons for departure. The register needs employment status for access cleanup, not the private story behind it.
Never track employee activity, productivity, content access, emails, documents, chats, or browsing behavior. CertPilot’s People & Accounts model is about ownership and status records, not monitoring people.
Never imply connector sync exists today. A manual register can be valuable without pretending to pull data from Google Workspace, Microsoft 365, HRIS, SSO, or an identity provider. If a future connector ships, it will need its own source-of-truth update and privacy process.
A cleanup pass for an existing spreadsheet
If Jordan already has a messy spreadsheet, the fastest path is not to start over. It is to normalize the fields.
- Split people and accounts into separate tabs or tables.
- Give every person a status: active, offboarding, left, or needs review.
- Standardize system names.
- Attach every account to a person or accountable owner.
- Replace free-text account states with a fixed status set.
- Add status changed dates where the status is disabled, deleted, or pending removal.
- Move passwords, recovery codes, and private notes out immediately.
- Mark unknowns as needs review instead of leaving cells blank.
- Export a dated snapshot after cleanup.
The first snapshot is not the finish line. It is the baseline for the next review.
How this supports access reviews and evidence reports
Clean account data is the input to access evidence. When the register knows people, systems, account identifiers, status, and dates, an access review can start from something credible instead of a reconstruction exercise.
The access review itself still happens in the Access Reviews module. The register supports it by keeping ownership and account context current. The completed review then becomes the dated artifact.
People and account information also rolls up into the cross-module Governance Evidence Pack as summary counts where specified. There is no dedicated People PDF today. The value is the maintained register, the accounts matrix, CSV import/export, and the way those records support access reviews and evidence reports.
For the wider operating model, read checks plus registers to evidence reports, public-signal checks vs internal registers, and how to show management that user access is under control.
How CertPilot fits
CertPilot’s People & Accounts Register gives lean teams a manual-first, CSV-friendly place for these fields. You can add people and accounts directly, import a spreadsheet, review the accounts matrix, and export records when leadership, a client, or an auditor asks for evidence.
The boundaries are explicit:
- CertPilot does not discover accounts automatically.
- CertPilot does not sync with Google Workspace, Microsoft 365, HRIS, SSO, or an identity provider today.
- CertPilot does not disable, delete, or deprovision accounts.
- CertPilot does not monitor employee activity, score productivity, or scan email, documents, chats, or files.
- CertPilot does not store secrets or credentials.
- CertPilot does not provide a dedicated People PDF report today.
- CertPilot supports operational evidence; it does not certify compliance or guarantee an audit outcome.
Those limits are not a weakness. They define the job: keep a clean, accountable record that makes manual review possible.
A practical first version
For a lean team, start with this minimum version.
Person fields:
- full name;
- work email;
- department;
- role or title;
- person type;
- status;
- start date;
- end date;
- notes.
Account fields:
- linked person or accountable owner;
- system;
- account identifier;
- account status;
- created date;
- status changed date;
- notes.
Review filters:
- people marked left with active accounts;
- people marked offboarding;
- accounts with no owner;
- accounts marked needs review;
- service or shared accounts;
- systems with inconsistent names;
- accounts without status changed dates.
This is enough to run the first meaningful review. More fields can come later, but only if they answer a real review question.
Example rows as plain English
A good manual register row should be boring. The boring rows are the ones reviewers can trust.
For an employee account: "Person: Jordan Lee, IT Operations, active employee. Account: Microsoft 365, jordan@example.test, active, created 2025-02-03, status confirmed 2026-07-31." That row answers who, where, and current state.
For a leaver: "Person: Sam Patel, Sales, left 2026-06-28. Account: HubSpot, sam@example.test, disabled, status changed 2026-06-28." That row connects the employment date to the account action.
For a shared mailbox: "Person owner: Priya Shah, Support Manager. Account: support@example.test, shared mailbox, active, status confirmed 2026-07-31, note: owned by Support Manager; not a personal mailbox." That avoids the common shared-account trap where nobody owns the login.
For a service account: "Person owner: Infrastructure Lead. Account: svc-deploy-prod, active, created 2024-11-02, status confirmed 2026-07-31, note: service account, no human login, rotation reference held in secrets manager." That records accountability without storing the secret.
For a vendor account: "Person owner: Finance Operations. Account: payroll-vendor-admin, pending removal, status changed 2026-07-25, note: vendor project ended; awaiting finance confirmation." That makes a lingering vendor login visible rather than silently acceptable.
Monthly review prompts
Once the fields exist, the monthly review can be simple. Ask these questions:
- Which people are marked left but still have active accounts?
- Which people are offboarding and need account-status follow-up?
- Which shared or service accounts lack a named accountable owner?
- Which account statuses changed this month?
- Which accounts are pending removal past the expected date?
- Which system names were entered inconsistently?
- Which accounts sit outside the access review scope but still matter?
- Which notes contain secrets or sensitive HR details that should be removed?
This turns the register from a static list into a maintenance routine. The evidence is not only the rows. It is the fact that the rows are reviewed, corrected, and exported on a cadence.
In short
- A manual accounts register needs a person layer and an account layer.
- Per person, track name, email, department, role, type, status, start date, end date, and notes.
- Per account, track system, account identifier, owner, status, created date, status changed date, and notes.
- Use standardized system names and status values.
- Never store passwords, secrets, sensitive HR detail, or activity-monitoring data.
- CertPilot records and organizes customer-maintained account evidence; it does not discover, sync, deprovision, or monitor accounts.
Frequently Asked Questions
What is the minimum I should track per account?
At minimum, track the system, account identifier, owner, and status. Add created date and status changed date as soon as possible. Without dates, the register can show a current state but not when that state became true.
Should shared accounts have an owner?
Yes. A shared account should have an accountable human owner even if several people use it. Use notes to explain that it is shared or service-like, but avoid leaving ownership blank.
Should I store passwords in the account register?
No. Never store passwords, recovery codes, API keys, private keys, or tokens in an account register. Use a password manager or secrets-management tool designed for that job.
Can I import an existing spreadsheet?
Yes. The useful first move is often importing the spreadsheet, standardizing system names and statuses, removing secrets, and marking unknowns as needs review.
Does CertPilot find accounts automatically?
No. CertPilot’s live People & Accounts Register is manual-first and CSV-friendly. It does not discover accounts automatically or sync with Google Workspace, Microsoft 365, HR systems, SSO, or identity providers today.