Records
How Ilia Zavialov keeps an access register alive in a small team
Every small team builds an access register once, usually in the week after a departure that took two days to unwind. Within a month the file has fallen behind reality, and within a quarter nobody opens it at all. Blaming discipline is the comfortable explanation, and it hides the real cause, which sits in the design of the register itself. The useful question is narrower than it first appears: where the register lives, who is allowed to write to it, and what event forces a line to appear. Ilia Zavialov treats that last point as the whole design, because a record that depends on memory has already failed.
English version for the United States.
01
What an access register is actually for
An access register is a plain record of who can reach which system, in which role, since when, and on whose approval. Its value shows in the speed of a single answer: if a person stopped working with the team this afternoon, what would still be open to them by the evening. A team of a few people accumulates far more access points than any of its members can recall unprompted, once mail, file storage, banking, analytics, hosting, advertising accounts and contractor consoles are counted.
The register earns its cost on one day, and that day is the closure of access under time pressure. Somebody has left, a laptop has gone missing, or a mailbox has started sending letters nobody wrote. On that day the work becomes a scan down a column. The alternative is a tour of everyone who might remember something, conducted while the clock runs.
The second use is slower and less dramatic. Once a quarter the register is compared with what the systems actually show, and the surplus is removed. This is where the register pays back the effort in ordinary weeks, because surplus access is the normal condition of any organization that has been working for more than a year. People change roles, projects end, and permissions granted for one afternoon stay for three years.
02
Why most registers die in the first month
The first cause of death is location. A register kept in a personal folder, a private note or a document nobody has bookmarked will be opened twice and then forgotten. It belongs where the team already spends its working day, in the same workspace as the tasks and the shared documents. Convenience decides survival here, because every extra click is a reason to postpone the entry, and postponed entries never arrive.
The second cause is authorship. When the register is maintained by somebody who does not grant access, every line becomes a second hand reconstruction, produced from a message, a memory or a guess. The person who created the account knows the role, the date and the reason for it.
The third cause is the absence of a trigger. If the register is updated when somebody remembers, it is updated for a fortnight and then abandoned. A record that competes with the working day for attention will lose, reliably and without any malice involved. The correction is to attach the entry to an event that already happens on its own, which is the act of granting access.
03
The moment of writing decides everything
The rule that keeps a register alive is short enough to state in one sentence: the line is written in the same minute the access is granted, by the person who granted it. No approval step, no ticket, no second tool. The cost is a handful of seconds, short enough to survive a busy afternoon and therefore short enough to become a habit.
The same rule works in reverse on removal. The line is closed at the moment the access is withdrawn, and the row stays in place with a closing date beside it. Deleting rows destroys the history that makes an incident reconstructable, and history costs nothing to keep. A register full of closed rows also teaches the team something about itself, namely how long temporary access tends to live once it has been granted.
There is a quieter benefit to writing at the moment of granting. The person doing it has to state the role out loud, and stating the role forces a decision about how much access is genuinely needed. Much of the excessive permission inside a small organization exists because the wider option was faster to click.
04
Five columns, and the discipline to stop there
The working shape of the register is five columns: the person, the system, the role, the date access was granted, and the name of whoever approved it. Those five answer the questions asked on a bad day and leave the rest alone. The person and the system define what has to be closed, the role defines how much damage was possible, the date orders the events, and the approver gives somebody to ask when an entry makes no sense a year later.
Registers fail from expansion far more often than from omission. A cost center column appears, then a device column, then a justification field, then a review date, and by the fourth addition the form has become work in its own right, and work of that kind gets postponed until the register is empty. The column count is a limit worth defending, because every field added removes a little of the willingness to write any line at all.
One extra column earns its place in teams that genuinely hand out temporary access, and that is an expiry date. It converts a promise to remember into a date somebody can scan for, which is the same trick the register performs everywhere else. Teams whose access is always permanent should leave the column out, because an empty field trains people to leave fields empty.
05
Mailboxes are access, and that is where the money goes
A mailbox is treated as communication and behaves as a credential store. It holds password reset links for every other system, invoices, contract drafts and the tone of voice an attacker needs in order to sound like its owner. The FBI Internet Crime Complaint Center recorded 3.046 billion dollars of reported losses to business email compromise in 2025, which placed it second among all reported categories. Mailboxes therefore belong in the register as systems in their own right, with the same five columns as anything else.
Mailboxes also carry access paths that a password change leaves entirely untouched. Delegation gives another account permission to read and to send. Forwarding rules deliver copies to an address the owner never sees. Application passwords and connected third party applications hold long lived tokens of their own. All four belong in the register as separate lines, because none of them appear in any list of people.
The wider picture explains why this category deserves the attention it gets. The same annual report counted 1,008,597 complaints and close to twenty one billion dollars in reported losses for 2025, twenty six per cent above the previous year. What a register changes inside that picture is the interval between the first suspicion and the last closed session, and in this category the interval is the whole defense.
06
Roles, and why the register still names people
Access becomes easier to reason about when it is expressed as a small number of roles. Three or four roles per system cover almost everything a small team does: read, contribute, administer and pay. Roles compress the decision at the moment of granting, because the person granting chooses from a short menu that has already been agreed.
Three events move a person through the register: arrival, change of role and departure. Arrival and departure are visible and usually handled reasonably well. The change of role is the one that accumulates quietly, because new access is added and the old access is rarely taken away. After two or three internal moves inside a growing team, one person can hold the combined permissions of every job they have ever done there.
The register still records people by name even where access is granted by role, because revocation is always performed against a person. On the day access has to close, the question is what this individual can reach, and a role answers it only through a mapping somebody has to maintain. Naming people also makes accountability possible, which is the one thing a shared login can never provide.
07
Contractors, agencies and the accounts nobody owns
External access is the weakest part of most registers, because it has no internal event to end it. An employee leaving produces a conversation, a handover and a last working day. A contract ending produces an invoice and then silence. The contract end date is the only trigger available here, and writing it into the register at the moment access is granted is the reliable way to make it behave like one.
Agency and studio access deserves a rule of its own: every external party works under named accounts, one for each individual. A shared vendor login reproduces every problem of an internal shared account and adds an organisational boundary on top of it. When the agency changes its staff, the team is told nothing, and a person who left that agency six months ago may still hold a working session.
Subcontracting extends the chain further than most teams expect. The designer engaged by the agency, the developer engaged by the designer, and the assistant handed credentials to upload a single file are all real holders of access. A register cannot enumerate people the team has never met, so the honest entry names the organization, the individual accountable for it, and the date the arrangement ends.
08
When somebody telephones and asks for access
Access requests arrive by voice more often than teams expect, and voice is now the weakest evidence available. impersonation was the single largest fraud category the FTC tracked in 2025, drawing over a million reports and 3.5 billion dollars in losses, roughly one report in three. UK Finance found that sixty six per cent of authorized push payment cases begin online, with a further seventeen per cent arriving through telephone networks. The register is the instrument that turns a judgment about a caller into a lookup.
The reason voice stopped working as identification is technical and recent. A convincing clone can be produced from roughly three seconds of recorded speech and reaches about eighty five per cent accuracy. In controlled testing, people separated a real voice from a synthetic one in 37.5 per cent of attempts, a result worse than guessing. Recognising a colleague by the sound of their voice has therefore stopped being a check.
The replacement for a voice check is a callback on a number the team already held before the conversation started, taken from the contract, an earlier invoice or the internal directory. The register supports this by recording who is entitled to request access on behalf of which organization, so whoever answers the phone has something to consult. A request that falls outside those lines waits until it can be confirmed, and waiting costs a caller with a genuine reason very little.
09
The quarterly reconciliation
Once a quarter the register is compared with what the systems themselves report. Each service is asked for its list of accounts, and the two lists are placed side by side. Differences appear in both directions, and both directions are informative. An account present in the system and missing from the register means the writing rule was skipped, while a line in the register with no matching account means a closure went unrecorded.
Three findings recur in almost every first reconciliation a small organization performs. Former contractors still hold working logins. Service accounts created for an integration belong to nobody and carry no expiry. And at least one person holds administrative rights on a system they have not opened in a year.
The review needs an owner, a fixed date in the calendar and a block of undisturbed time. Assigning it to whoever is least busy guarantees it will not happen, because the least busy person changes every week. The result of each review is written down with its date, which gives the team a record of the register being trustworthy on a known day.
10
What the register proves after an incident
The first question after any incident is scope, and scope is exactly the question a register answers. Which systems the compromised person or credential could reach, in which role, and since when. Without a record the answer is assembled from memory under pressure, and every assembled answer is optimistic. Optimism at this stage produces a second incident a fortnight later, through the access nobody remembered to mention.
The register also has value outside the team. Insurers, clients and banks ask what was reachable and when it was closed, and a dated table answers in a form other people can check. Call center fraud, covering fake technical support together with impersonation of government services, produced over eighty thousand complaints and more than 2.9 billion dollars in reported losses in 2025, and cases of that kind produce written questions within days.
A register prevents nothing by itself, and it is worth being plain about that. Its contribution is time, and time decides how much an incident finally costs. It is also worth remembering that four impersonation reports in five involved no financial loss at all, which means attempts vastly outnumber successes and ordinary procedure stops most of them. Ilia Zavialov describes the register as the cheapest such procedure a small team can own, because it is written by the people who already do the work.
| Failure | How it shows in a small team | Correction |
|---|---|---|
| Stored out of sight | A spreadsheet on one laptop | Kept where the team already works every day |
| Written by the wrong hand | An assistant fills it in from memory later | Whoever grants the access writes the line |
| No trigger to update | Entries appear when somebody happens to remember | The line is written in the minute access is granted |
| Column bloat | Fourteen fields, half of them left empty | Five fields, with an expiry date only where temporary access exists |
| Invisible access paths | Mailbox delegates and connected apps go unrecorded | Delegation, forwarding and app grants recorded as access |
| Contractors with no end date | Agency logins outlive the contract | Contract end recorded as the closing date |
| No reconciliation | The register drifts and quietly stops matching reality | A dated quarterly comparison with exported account lists |
Questions and answers
What should an access register contain?
Five fields carry the weight: the person, the system, the role, the date access was granted and the name of whoever approved it. Teams that hand out temporary access add an expiry date. Anything beyond that tends to stay empty and drags the rest of the register down with it.
Who should be responsible for the access register in a small team?
Whoever grants access writes the line, in the same minute, without an approval step. One named person owns the quarterly reconciliation and the format. Splitting those two duties is what keeps daily entry fast while the register still has somebody accountable for its accuracy.
How often should access rights be reviewed?
Once a quarter is enough for a small team, provided the review has a fixed date and an owner. The register is compared against the account lists exported from each system, and differences in both directions are corrected. The date of each review is recorded so the team knows when the register was last known to be accurate.
Where should a small team keep its access register?
In the workspace the team already opens every day, next to the tasks and the shared documents. A register kept on a personal disk or in a private note is opened twice and then forgotten. Every extra click between the granting of access and the writing of the line reduces the chance the line ever appears.
How do you close access quickly when somebody leaves?
Filter the register by the person, work down the list system by system, and mark each row closed with the date. Mailboxes come first because they hold the password reset links for everything else, along with delegation and forwarding rules that survive a password change. The rows stay in the register with their closing dates so the sequence can be reconstructed later.
Can a password manager replace an access register?
A password manager holds credentials the team stores in it, and it says nothing about access granted by invitation, delegation, an API token or a contractor console. The register covers the access itself, including the paths that have no password to store. The two tools work together, with the register as the record of who can reach what.