Periodic Access Reviews for Transfer Accounts

Somewhere on your transfer server, right now, there is probably an account that should not exist. It belongs to a contractor whose project ended, a partner whose contract lapsed, or an employee who changed roles two reorganizations ago. Nobody decided to keep it. It exists because removing access requires someone to notice, and noticing is nobody's job. Access is granted with fanfare and forgotten in silence. (The "probably" is politeness. I have never pulled a first account list and found nothing.)

The periodic access review — also called recertification — is the scheduled ritual that makes noticing someone's job. On a recurring calendar, typically every quarter, you pull the complete list of transfer accounts. Put each one in front of a person who can vouch for it. Record the verdicts, remove what nobody defends, and file the whole exercise as evidence. It is unglamorous, it takes an afternoon, and it is one of the highest-value controls a transfer system can have. That is true both for security and for the audit, where "show me your last four access reviews" is among the most common requests.

This article is a working manual. It covers why access rots and what counts as an account. It gives you a step-by-step walkthrough with realistic findings, a copyable attestation record, and the details that make the review itself stand up as audit evidence. It is part of our Audit-Ready Reporting series.

Why Access Rots

Access has a one-way valve built into organizational life. When someone needs access, they ask loudly and soon — work is blocked. When they stop needing it, they ask nobody, because nothing is blocked and there is no moment where the need visibly ends. Multiply that asymmetry by every joiner, mover, and leaver, and access quality decays on its own schedule. Nobody waters the account list; it grows anyway.

The decay takes recognizable forms. An orphaned account outlives its owner's employment or contract — the classic leaver gap. It is dangerous because the credentials may still work and nobody is watching the account's activity; finding stale and orphaned accounts is the hunt for these between reviews. A dormant account belongs to someone still around who simply stopped using it; dormancy is how you spot needs that quietly ended. Privilege creep is subtler. A person accumulates rights across role changes because each move added access and none removed any. Eventually their profile reflects their career history rather than their job — the mechanism role changes and permission creep takes apart. And unowned service accounts — automation credentials whose creator left — drift along with nobody able to say what breaks if they are disabled. (The usual way to find out is to disable them.)

None of these is caught by good intentions, because each is invisible in daily operation. They are caught by comparing the full list against current reality on a schedule — which is the entire idea of the review. It is also why auditors care about recurrence. One immaculate review proves a moment. A series of them, each dated, proves the control operates — the design-versus-operating distinction from what auditors actually ask.

There is a security argument here as strong as the audit one. Every enabled account is attack surface: a set of credentials that can be phished, guessed, or bought, attached to whatever the account can reach. An orphaned account is the attacker's favorite kind — valid credentials, real permissions, and an owner who will never notice unusual activity because there is no owner. Trimming the account list is one of the few controls that reduces risk by subtraction, a theme explored in the blast radius of one account. The review is where the subtraction happens on schedule.

What Counts as an Account Here

The review is only as good as its population, so define "account" generously. Four categories belong on the list:

• Human users — employees and contractors with interactive access to the transfer system.
• Partner accounts — external organizations that connect to exchange files. These rot on a different clock (contracts end, integrations get replaced) and their lifecycle deserves its own discipline; see partner credential lifecycle.
• Service accounts — the non-human credentials that scripts and scheduled jobs sign in with. These are the accounts most often skipped and most dangerous to skip, because they tend to hold broad rights and eternal passwords. Our article on service account hygiene covers what good looks like.
• Administrators — the short list with the keys to everything, reviewed with extra care and ideally by someone other than the administrators themselves.

Then make sure you are pulling from every source of accounts, not just the obvious one. On a Windows server such as Sysax Multi Server, authentication can come from accounts built into the server, from Windows or Active Directory, or from SFTP public keys. Those are three separate places access can live. A review that covers only one is an audit finding waiting to be written. Two adjacent populations ride along with the account list. One is the folder permissions each account holds, whose own checkup is covered in auditing permissions. The other is the keys that authenticate accounts. A public key left in place is standing access no password reset revokes. That is why retiring keys during offboarding pairs naturally with this review.

The Review, Step by Step

The full cycle below is walked through as it plays out at a realistic small firm: one transfer server, twenty-seven accounts, quarterly cadence, one admin (you) running it.

1. Pull the population. Export the complete account list from every source, system-generated and dated: account, source, rights, status. Enrich it with each account's last sign-in from the activity logs. A server that logs to a database makes this a query rather than a trawl. If you built the account-access standing report from the transfer reports worth automating, this step is already done: the review consumes that report.
2. Enrich with ownership. For each account, note the person who can vouch for it: the employee's manager, the partner relationship's business owner, the service account's named owner. Gaps in this column are themselves findings — an account nobody can vouch for has failed the review before it starts.
3. Distribute for attestation. Send each certifier their slice with a plain question: for each account, keep, modify, or remove — and for "keep," a one-line business reason. Give a deadline about two weeks out. Keep the ask small; a certifier facing four accounts answers today, one facing a spreadsheet of four hundred defers forever.
4. Chase, then default to deny. Chase non-responders twice. After that, the safe convention many organizations adopt is: no answer means suspend. Disable the account rather than delete it, so a genuine need resurfaces as a quick re-enable, not a data-loss incident. What you must not do is let silence mean "keep"; that converts the review into theater.
5. Execute the changes. Disable the removals, trim the modifications, ticket each change so the config-change log and the review record corroborate each other.
6. Verify. Re-pull the account list and confirm every decided change actually took effect. Skipping this step is the most common real-world failure: decisions recorded, execution assumed, and the orphaned account survives its own removal.
7. File the evidence pack. Population export, attestations, decisions, tickets, and the verification re-pull — all dated, all in the quarter's folder of the evidence tree described in transfer evidence auditors accept.

The quarter's findings in our twenty-seven-account example were a typical haul:

Four findings out of twenty-seven is not a sign of failure — it is the review working. A review that finds nothing, quarter after quarter, in a living organization, is the suspicious result.

Northgate Retail's reviews had found nothing for six quarters, which the IT manager had taken as good news. The auditor took it differently. She pulled the six attestation sheets and noticed that every "keep" had been entered in the same minute. The reasons column was blank all the way down. So she sampled four accounts herself. She found a merchandiser who had left the previous spring and a partner login for a courier Northgate no longer used. Neither account had been touched since, which was the only lucky part. The review was rebuilt around one-line reasons and slices of six accounts per certifier. The next quarter's version found five things and took an afternoon.

The Attestation Record

The attestation record is the document that captures the whole exercise. Keep it plain and consistent, and copy the template rather than inventing one:

TRANSFER ACCOUNT ACCESS REVIEW  --  attestation record

review period:   second quarter
scope:           TRANSFER01 - all account sources (built-in,
                 directory, public-key), all folder rights
population:      accounts-export_pulled-02jul_rm.csv (27 records,
                 reconciled against directory group same day)
coordinator:     R. Mercer (admin)

ACCOUNT      TYPE      OWNER       DECISION  REASON / ACTION
mfrost       human     J. Alvarez  remove    leaver; ticket 341
acme-inbound partner   T. Osei     suspend   dormant 2 qtrs; ticket 342
svc-nightly  service   R. Mercer   modify    trim rights; ticket 343
dkim         human     P. Nassar   modify    role change; ticket 344
(23 further accounts)              keep      attested, reasons on file

attestations:    collected 03jul-16jul, copies filed with record
actions done:    tickets 341-344 closed 18jul
verification:    list re-pulled 19jul; all decisions confirmed
                 in effect; re-pull filed with record
sign-off:        R. Mercer 19jul / K. Whitfield (IT manager) 21jul

next review due: first month of next quarter

Every line earns its place under audit questioning. The population line shows completeness, and the ticket numbers tie decisions to execution. The verification line proves the changes took. The two sign-offs show the review was not the admin grading their own homework.

Making the Review Itself Auditable

When an auditor tests this control, the pattern is predictable. They pick one or two past quarters. Then they ask for the population that was reviewed, the attestations behind a sample of "keep" decisions, and proof that the "remove" decisions actually happened. That proof is typically the ticket plus an account list from after the review showing the account gone. Design your record-keeping so those three pulls are trivial, and the test passes itself.

Four traps produce most failures of this control, and all four are avoidable:

• The undated list. A population export with no pull date and no source cannot anchor anything. Date everything, name the source system, state the record count.
• The rubber stamp. Forty accounts approved in three minutes, no reason given for any, nothing ever removed — a pattern reviewers can see and discount. Requiring a one-line reason per "keep" is the cheapest cure, and it is why small certifier slices matter.
• Decisions without execution. The record says "remove" and the account still signs in a month later. The verification re-pull exists precisely to kill this gap, and it is the first thing a thorough auditor checks.
• The missing quarter. Three reviews out of four is a hole in operating effectiveness that no quality in the other three repairs. Recurrence is the control; protect the calendar slot like a patch window.

Cadence and Scope: Who Decides, and How Often

How often is often enough? Every quarter is the common rhythm for transfer systems that face partners or carry regulated data. Some organizations review administrator and privileged accounts more often and low-risk internal accounts twice a year. Here is the honest division of labor. Your compliance function or the frameworks you answer to set the cadence the organization commits to. The administrator's job is to run the ritual on that calendar and evidence it. If no one has set a cadence, propose quarterly. That is frequent enough that each review is small, infrequent enough that nobody dreads it, and regular enough that the calendar does the remembering.

Scope can be tiered the same way. Every review covers all accounts at least lightly (does it still have an owner? has it signed in?). The deep attestation rotates emphasis — partner accounts one quarter, service accounts the next. That way, the heavy scrutiny lands everywhere across a year without any single quarter ballooning.

The calendar is the backbone, but some events justify an off-cycle look at a slice of the list without waiting for the next quarter. These include a reorganization that moves whole teams, a partner relationship ending, an administrator departing, or an incident that touched credentials. These event-driven mini-reviews are narrow — just the affected accounts — and they close the window between "the world changed" and "the account list caught up." Note them in the same evidence tree. An auditor who sees both a steady quarterly rhythm and prompt event-driven checks is looking at a control environment, not a ceremony.

The First Review: Expect Archaeology

A warning that doubles as encouragement: the first review is nothing like the quarterly rhythm that follows. If the transfer server has run for years without recertification, the first population pull is an archaeological dig. You find accounts named after people no one remembers, and partner credentials for companies that changed names twice. You find a service account called temp2 with write access to everything and no documentation at all. Expect the findings list to be long, and expect a handful of accounts where the only honest attestation is "unknown." Nobody will remember creating temp2. Someone will remember temp1.

Do not let the size of the first haul stall the ritual. Suspend the unknowns rather than researching each to its origin. Record the mess honestly, because a first review that documents twelve removals is not an embarrassment. It is the before-and-after picture that proves the control was worth installing. The second review will be a fraction of the effort, and by the third the whole thing runs on rails. Auditors read that trajectory the right way: they typically care far less about the mess you inherited than about the evidence you are systematically clearing it.

Making It Less Painful Every Quarter

The first review is the hard one; the rest can be mostly assembled from parts that already exist. Let the standing account-access report supply the population, so step one is opening a file, not building one. Schedule the kickoff mechanically. A job in Sysax FTP Automation can deliver the quarter's population export to the review folder on the calendar and email the team that the package is ready. That turns "remember to start the review" into "the review started itself." Pre-fill this quarter's sheet with last quarter's decisions and highlight only the differences — new accounts, changed rights, fresh dormancy. That way, certifiers attest deltas, not the whole world. And shrink the population permanently where you can. Every account and permission that exists is one more row to review forever. That is a quiet argument for the least-privilege designs in our least privilege in practice guide.

Run this way, the quarterly review settles at about an afternoon for a modest estate. It becomes one square on the larger calendar of recurring control tasks that from annual audit panic to continuous compliance assembles.

The Short Version

Access rots by default; the periodic review is the scheduled counterweight. Pull a complete, dated population from every account source. Put every account in front of someone who can vouch for it. Let silence mean suspend, never keep. Execute, verify, and file the pack — population, attestations, tickets, re-pull, sign-offs. Do it every quarter without missing one, and you get the double payoff this whole series is about. You get a transfer system with less standing risk, and an audit answer that consists of opening a folder. The one-minute version is faster, and it is the one that finds nothing.

Frequently Asked Questions