What to Track in a Manual Accounts Register (Fields That Make It Evidence)

A manual accounts register should track, per account: the system the account is on, the account identifier, the person who owns it, its status, the date it was created, the date its status last changed, and a free-text note — with each account attached to a person record carrying name, work email, department, role, type, status, and start/end dates. Those columns are what turn a flat list of logins into something you can actually review.

This is the field-level setup guide. For what a register is and why a lean IT team needs one, start with what a people and accounts register is; here we go straight into the columns.

Why Manual Account Evidence Gets Messy

Without connectors, account data is assembled by hand — and it degrades in predictable ways. A spreadsheet starts clean, then someone adds a column no one else fills in, a leaver is never marked, two people track the same SaaS tool under different names, and "status" becomes a mix of yes, active, and an empty cell. Six months later it is a list nobody trusts.

The fix is not more columns — it is the right, consistent columns, filled the same way every time. The rest of this article is that field set, grounded in what the live People & Accounts register tracks today, so the structure you build by hand maps cleanly onto the product if you adopt it.

The Field Set at a Glance

| Field group | Example fields | Why it matters | Review use | |---|---|---|---| | Person identity | Full name, work email, department, position/title | Settles who the account belongs to | Defines the population under review | | Person lifecycle | Type (employee/contractor/other), status (active/offboarding/left), start date, end date | Flags who is leaving or already gone | Surfaces leavers whose accounts may still be live | | Account identity | System, account identifier | Names the access precisely | Lets a reviewer find and verify the account | | Account status & dates | Status (active/disabled/deleted/pending removal), created on, status changed on | Records the account's current state and when it changed | Shows whether access was acted on, and when | | Notes / exceptions | Free-text notes on the person or account | Captures context a column can't | Explains shared logins, service accounts, exceptions |

Person-Level Fields to Track

An account is only meaningful once it is tied to a person. The person record carries:

• Full name (the one required field) and work email — the identity the account links to.
• Department and position / title — context that makes "does this access fit the role?" answerable.
• Type — employee, contractor, or other. Contractors are exactly the records that go missing, so the type field earns its place.
• Start date and end date — the employment window.

Keep this side lean. It is not an HR profile; it is just enough about the person to make their accounts reviewable. For the relationship between people and the systems they hold, see how a people & accounts register supports access reviews.

Account-Level Fields to Track

Each account is its own row, attached to a person. The live account record tracks:

• System — the tool the account lives on (required). This is the link between a person and a specific access point.
• Account identifier — the username, email, or login that names the account on that system. This is what a reviewer uses to find and confirm it.
• Notes — free text for anything a column can't hold: "shared mailbox," "service account, no human owner," "license seat 4 of 5."

The owner is not a separate column — it is the person the account is attached to. Attaching every account to a person record is how ownership gets recorded, which is why there are no orphaned-account rows with a blank owner field by design.

System and Vendor Fields to Track

The system field is deliberately flexible: pick from your catalog of known systems, or enter a custom name for a one-off tool. Two disciplines keep it useful:

• Name each system one way. "M365," "Microsoft 365," and "Office" as three values fracture the register. Agree on one label per system.
• Align system names with your access review. The Access Reviews systems catalog defines the columns of the review matrix; using the same system names in both means the account register lines up with the review instead of fighting it.

The register tracks the account on a system, not the contract behind it. Vendor renewals, costs, and contract dates belong in the Renewals & Vendor Register, and hardware or software inventory in the Assets Register — keep those facts there rather than overloading account notes.

Status and Lifecycle Fields to Track

Status is where a register proves it is current rather than historical. Two status fields do the work:

• Person status — active, offboarding, or left. Marking someone offboarding or left is what makes their lingering accounts visible.
• Account status — active, disabled, deleted, or pending removal — paired with created on and status changed on dates.

One caution that is also a product boundary: a status of disabled, deleted, or pending removal is a record that an action was taken (or is due) in the underlying system. The register does not remove access, disable accounts, or deprovision anyone — you do that in the system itself and record it here, with the date in status changed on. That dated record is the evidence; the action lives elsewhere.

Review-Readiness Fields to Track

"Review-ready" is not a separate set of columns — it is a property the fields above produce when filled consistently. A row is ready for an access review when three things are true:

1. It has an owner (it is attached to a person).
2. It has a current status with a status-changed date.
3. Its system name matches the one used in the review.

If those hold for every row, an access review starts from real data instead of reconstruction. A register that admits "we are unsure about these three accounts" via an honest status and a note is more review-ready than one that pretends to be complete.

What Not to Track

A register earns trust by what it refuses to hold. Never put these in it:

• Passwords, secrets, API keys, or recovery codes — never. A record of which accounts exist must not become a credential store; one leaked spreadsheet would then expose every system at once. Keep secrets in a password manager built for them.
• Sensitive HR data — payroll, performance, health, disciplinary notes. That belongs in an HR system.
• Employee behavior. The register records that an account exists and who owns it, not what anyone did, sent, or opened.

This restraint is the point: the register's job is to make access accountable, not to enlarge the pool of sensitive data IT must protect.

How This Supports Access Reviews and Evidence Reports

Clean fields are the input to the governance work. A well-kept register feeds an access review directly — owner, status, and system are exactly what a reviewer needs — and the completed review produces the dated artifact. People and account information also rolls up, as summary counts rather than names, into the cross-module evidence reports alongside domains and renewals. This is the checks + registers → evidence reports model in practice, and the difference between public-signal checks and internal registers: no external scan can see an account on a niche SaaS tool, so the register is where that knowledge becomes real governance evidence. The sample reports gallery shows the output.

How CertPilot Fits — With Strict Boundaries

CertPilot's People & Accounts register is a manual-first, CSV-friendly home for exactly these fields: add people and accounts directly or import a spreadsheet, keep status and dates current, and use the accounts matrix to scan people against systems. It helps a team prove IT is under control without another pile of spreadsheets. What it records is operational evidence you maintain — and the limits matter as much as the fields:

• It does not discover accounts automatically or sync with Google Workspace or Microsoft 365 today. It is only as complete as you keep it.
• It does not remove, revoke, or deprovision access. Those actions happen in each system; the register records that they were done.
• It does not monitor employee activity, score productivity, or scan email, documents, chats, or files.
• It is not a certification or an audit guarantee. It supports internal governance routines and evidence preparation.

A Practical First Version for a Lean IT Team

You can build a usable register this week:

1. List people first — name, work email, department, role, type, and status. Mark anyone you know is leaving as offboarding.
2. Add the accounts that would hurt to forget — email, core SaaS tools, and admin consoles — recording system, identifier, and status for each.
3. Set status and dates honestly, including status changed on whenever you disable or remove an account in the underlying system.
4. Import rather than retype. If the data is already in a spreadsheet, bring it in by CSV and clean it in place.
5. Pick a review cadence — monthly or quarterly — to walk the list, update statuses, and resolve anything with no clear owner.

The first pass will be imperfect, and that is fine — the register improves through review, which is the governance work you needed to show anyway.

In Short

• Per account, track system, account identifier, owner (via the person), status, created-on, status-changed-on, and notes; per person, track name, email, department, role, type, status, and start/end dates.
• Consistency beats column count: one label per system, one way to fill status.
• Disabled / deleted / pending removal are records of actions taken elsewhere — the register does not perform them.
• Never store passwords, secrets, or sensitive HR data.
• The same fields that make a row clean make it review-ready and report-ready.

Frequently Asked Questions

What is the minimum I should track per account?

At minimum: the system, the account identifier, the owner (by attaching the account to a person), and the status. Add created on and status changed on as soon as you can — without dates, the register proves a state but not when it was true.

Should I store passwords in the register?

Never. A register lists which accounts exist; it must not hold credentials. Storing passwords turns one leaked file into a master key for every system. Keep secrets in a dedicated password manager and keep the register to facts about accounts, not access to them.

How do I track shared or service accounts?

Attach them to the person responsible for them and use the notes field to record that the account is shared or a service login — for example, "shared support mailbox" or "service account, owned by IT." The owner is the accountable person, not necessarily a daily user.

Can I import my existing spreadsheet?

Yes. The register is CSV-friendly: import what you already have, then clean it in place — standardize system names, fix statuses, and fill in owners. CSV export keeps the data portable when leadership, a client, or an auditor asks for it.

Does the register find accounts I forgot?

No. It does not discover accounts automatically or sync from any system — it reflects exactly what you enter or import. Completeness is a habit, not an automation: the periodic review is how forgotten accounts get caught and added.