The Transfer Reports Worth Automating

It is nine in the evening, and the request is due Friday. The query that would have taken ten minutes in March is taking three hours in September, because the March logs rolled over in July. That is one of the two ways to produce the reports an audit asks for. You reverse-engineer months of history under deadline, hoping the logs still cover the period, formatting spreadsheets by the light of the monitor. The other is to open a folder where the reports have been quietly accumulating all year, generated on a schedule by a job that never forgets. Then you hand over exactly what was asked for.

The second way is not a luxury reserved for large teams. I have done it both ways, and the second is the reason I still have evenings. It takes a modest one-time investment: decide which reports matter, make each one audit-grade, and put it on a calendar. This article covers all three steps. It covers the five standing reports that between them answer most transfer audit requests. It explains the header discipline that makes a report count as evidence, and the scheduling and review habits that keep the whole thing honest. It is the third article in our Audit-Ready Reporting series.

Why Standing Reports Beat Heroic Queries

A standing report is a report generated automatically on a fixed schedule, in a fixed format, and filed without anyone asking for it. It differs from a canned report — a saved query you run on demand. That is the tool covered in our logging series article on audit-ready reporting from transfer logs. The difference is exactly one thing: nobody has to remember. The canned report is the query; the standing report is the query on a calendar, with delivery and filing attached.

Three reasons the schedule matters more than it looks. First, operating effectiveness. As explained in what auditors actually ask, most audit questions require proof that a control worked across the whole period, not just today. A report generated monthly all year is period-long evidence by construction. A report built during the audit only shows what the surviving records happen to support. Second, contemporaneous records carry more weight. A file dated the third of each month, twelve months running, is hard to argue with. A batch of files all created the week the auditor arrived tells its own story. Third, you actually find problems. The dormant account, the partner whose uploads quietly stopped, the certificate about to expire — standing reports surface these while they are still cheap to fix. That is the operational payoff that makes the audit payoff nearly free.

The Five Reports

These five cover the great majority of transfer evidence requests. Each is described by the question it answers, what belongs in it, and its natural cadence.

Report one: account access

The question it answers: who can touch the transfer system, and at what level? One row per account: account name, where it comes from, what it can reach, its owner, its last sign-in, and whether it is enabled. The "where it comes from" column deserves emphasis. On a server such as Sysax Multi Server, accounts may be built into the server, come from Windows or Active Directory, or authenticate with public keys. A report that covers only one source is the incomplete population that undermines audits. Cadence: monthly, or quarterly at minimum. This report is also the raw material for the recertification ritual in periodic access reviews for transfer accounts. The last-sign-in column is what turns it from a list into a finding-generator: dormant accounts announce themselves.

Report two: transfer activity

The question: what actually moved? Summarized per account, partner, or sensitive folder: sessions, files uploaded and downloaded, bytes, and failures, with the detail records available underneath. This is the report that answers "show me all access to the payroll folder for the quarter" — the single most common evidence request. It makes that a lookup rather than an investigation. Cadence: monthly for the summary. The underlying logs remain the fine-grained record. Knowing how to read them (see reading transfer logs) is what lets you answer follow-ups.

Report three: failed sign-ins and lockouts

The question: is anyone knocking on the door, and would you notice? Failed authentication attempts grouped by account and source address, lockouts triggered, and notable patterns — one address probing many accounts, one account failing from many addresses. This report is your standing answer to the auditor's "how would you detect a brute-force attempt?" It doubles as a genuine security control. The patterns worth flagging are covered in monitoring authentication attacks. Cadence: weekly, because this one is about noticing, not just recording.

Report four: configuration and administrative changes

The question: who changed the system, and was each change supposed to happen? Account creations and deletions, permission changes, protocol and setting changes, with the administrator responsible for each. Auditors typically sample from exactly this list and ask for the approval behind each item. So the report is both the population and the reconciliation tool. Someone who is not the administrator reviews it against the period's change tickets. Cadence: monthly. This is also the report that answers the quiet question behind many audits — who watches the administrators? (Ideally, not only the administrators.)

Report five: exceptions

The question: what went wrong, and what did you do about it? Failed scheduled jobs, transfers that never arrived, refused connections from allowlisted partners, certificates approaching expiry — every event that deviated from routine, each with a disposition: what happened next. This is the report that proves monitoring is real. Individual failures should already reach you as they happen, through job notifications and alerts. The weekly exceptions report is the roll-up that shows every one of those events was seen and handled, not just emitted. Cadence: weekly.

The five line up against the five question themes from the auditor's standard set. The access report answers the access theme. Failed sign-ins answers authentication's "would you notice" half. Transfer activity and configuration changes answer the data-handling and change questions. The exceptions report — plus the review traces on all of them — answers the theme that fails most first-time auditees: who reviews it. Build these five and you have pre-answered most of the interview.

Anatomy of an Audit-Grade Report

A report becomes evidence when it carries its own provenance — the properties described in transfer evidence auditors accept and reject. In practice that means every generated file opens with a header block stating what it is, where it came from, and how complete it is. Build the header into the export job once and every future report inherits it:

REPORT HEADER TEMPLATE  --  first lines of every generated file

report:      transfer-activity-summary
source:      TRANSFER01 activity database
generated:   Jul 01 06:10 by job rpt-activity-monthly
period:      Jun 01 00:00 through Jun 30 23:59
scope:       all accounts, all folders, both servers
records:     4,382 detail rows summarized; 0 excluded
query:       stored with this report as query.txt
exceptions:  none  (or: listed at top, each with disposition)

Three header lines do most of the audit work. Generated-by makes the report system-generated on its face. Period and scope state the population claim explicitly, so completeness can be tested rather than assumed. Record count lets anyone verify that the file they received is the whole file. Keep the format identical month over month — auditors sample several periods, and identical shape makes their comparison, and your credibility, easy.

Scheduling So Evidence Collects Itself

Now the honest tooling story. A transfer server is a system of record, not a reporting engine. Sysax Multi Server, for instance, logs all activity to file and to a database with rollover to keep files manageable. That is precisely what you want from a source: complete, queryable raw material. The report layer on top is yours: a small script or query per report. It is owned like any other piece of infrastructure — in version control, with a named maintainer. This is less glamorous than a reporting product and considerably more defensible in an audit, because you can show exactly how every number is derived.

The delivery layer is where scheduling tools earn their keep. A scheduled job can run the export, move the output to the evidence share, and announce the result. With Sysax FTP Automation, the transfer of the report file to its destination runs on the calendar with retry and error handling. The email notification tells the team the job ran or, more importantly, that it did not. A few scheduling habits worth adopting:

• Run just after the period closes — the morning of the first, not the stroke of midnight — so late-arriving log entries are included and the period boundary is clean.
• Stagger the jobs. Five reports at the same minute compete for the same database and fail together; spread them across the morning.
• Name outputs by convention, the same one your evidence tree uses: what it is, the period, the generating job.
• Watch the watcher. The report job that silently stops is the classic audit-eve discovery. The absence of an expected email is itself a signal — but only if someone would notice. A monthly one-line check that all expected files exist closes the loop.
• Keep the source healthy. Reports inherit every weakness of the logs beneath them — coverage gaps, short retention, a single copy on the server itself. The groundwork articles on what to log and centralizing logs are prerequisites, not options.

The Report Nobody Reads

The failure mode that turns all this machinery into shelf-ware is simple: reports generate perfectly, land in the folder, and nobody opens them. To an auditor this is worse than having no reports, because it demonstrates that your monitoring control is decorative. The question that follows the proud tour of your automation is always the same: "who reviews these, and can you show me the review?" The folder, for its part, has never once complained about being ignored.

Kestrel Payroll had the generation half working beautifully. The weekly exceptions report ran every Monday and was delivered to a shared mailbox. It was filed by a rule nobody remembered writing into a subfolder called Reports. When the auditor asked to see the review trace, the subfolder held forty-seven reports, all unread. One of them showed that a partner's uploads had stopped five weeks earlier. The finding said the control "was not evidenced as operating," which was a polite way of putting it. The fix was a rota and a reply-to-the-email habit. The cost was three weeks of retrofitted review and a phone call to the partner that nobody enjoyed.

So build the review in as deliberately as the generation. Give every report a named reviewer — a role, not a volunteer — and a lightweight way to leave a trace. That could be a reply to the delivery email ("reviewed, one anomaly, ticket 218"), initials in a review log, or a ticket for each exception pursued. Design the reports themselves for a ten-minute review: exceptions and anomalies at the top, routine volume below, so attention lands where it matters. Auditors typically test review the way they test everything — pick four weeks at random, ask for the trace from each. A thin but consistent trail passes where a thick, sporadic one fails.

One report deserves a different reviewer than the rest. The configuration-change report describes the administrator's own actions. A control where someone reviews only themselves is a control auditors typically discount. The principle is called separation of duties: the person who performs an action should not be the only person who checks it. In a larger team, a second administrator or a manager reviews the change report against the period's tickets. In a one-admin shop, improvise honestly. The manager can review it even without deep technical knowledge ("were all of these changes ones we asked for?"). Or an admin from a neighboring team can swap review duty with you. Imperfect separation, documented, beats none.

For events that cannot wait a week — a lockout storm at two in the morning, a critical job failure — reports are the wrong tool. That is alerting territory, covered in alerts from transfer logs. The two mechanisms complement each other: alerts catch the event, reports prove the pattern and the review. (A live dashboard, the subject of building a server health dashboard, is the present tense of the same story.)

How Long to Keep the Reports

Two rules keep report retention simple. First, reports do not replace logs. The report is a summary; the log is the record. Keep both, because follow-up questions ("that June anomaly — show me the sessions behind it") are answered from the detail the summary was built on. Second, retention periods are policy decisions, not admin preferences. How long each report and its source logs must survive is set by your organization's retention schedule. Compliance and legal own those numbers, which vary by framework and industry. Your job is to implement them faithfully and to be able to show that you did. As a floor, keep every period's reports at least until the audit cycle that examines that period has fully closed. Treat the evidence tree's older folders as read-only archives rather than working space.

The auditor's request reads: "Provide evidence that transfer failures were detected and resolved throughout the period." Without standing reports, that is a two-week archaeology project, with you as both the archaeologist and the ruins. With them, the response is assembled in twenty minutes. It includes the period's weekly exception reports — each with its header, each with a review trace. It also includes the tickets behind a handful of the exceptions, pulled as examples. The population is the report series itself; the samples are ready before they are requested. That is what "evidence collects itself" means in practice.

A Starter Schedule

Do not build all five reports this week. Start with the two that pay off fastest — account access and exceptions — and add the rest as each becomes routine. A working starter calendar:

STANDING REPORT SCHEDULE  --  starter version

weekly, Monday 06:00     failed sign-ins        review: admin, same day
weekly, Monday 06:15     exceptions             review: admin, same day
monthly, 1st 06:30       account access         review: admin; owners quarterly
monthly, 1st 06:45       transfer activity      review: admin + flow owners
monthly, 1st 07:00       config changes         review: manager or second admin

each job:  export -> deliver to evidence share -> email result
each review:  leaves a trace (reply, initials, or ticket)

Within a quarter you will have something quietly remarkable: a folder of consistent, provenance-carrying, reviewed reports covering the entire period. That is the exact material that makes an audit request a lookup. The next article, periodic access reviews for transfer accounts, takes report one and builds the recertification ritual on top of it. The habit of running your whole control set on a calendar is where this series lands in from annual audit panic to continuous compliance.

What to Take Away

Five reports — account access, transfer activity, failed sign-ins, configuration changes, exceptions — answer most of what auditors ask about a transfer system. Make each one carry its provenance in a header and generate on a schedule slightly after the period closes. Have it land in the evidence tree and get read by a named person who leaves a trace. The server's logs are the source of record; the scripts are yours; the calendar does the remembering. That is the whole design, and it is within reach of a one-person IT team. It is the difference between September at nine in the evening and September at home.

Frequently Asked Questions