Audit-Ready Reporting from Transfer Logs

An audit or an evidence request tends to arrive as a fire drill. Someone forwards an email — "the auditor needs all access to the payroll folder for last quarter by Friday" — and a scramble begins: which server, which logs, are they still around, how do we pull just that folder, how do we prove the list is complete. Teams that have not prepared spend the week taking screenshots and stitching spreadsheets together by hand, and still hand over something they are not sure is complete.

It does not have to be like that. Every one of those requests is answerable from logs you already keep — if you have done three things in advance: learned to translate what a request is really asking into a query your logs can answer, built a small set of canned reports once so you are not reinventing them under deadline, and set a retention policy that guarantees the data is still there when asked. This article covers all three, and it is where the whole logging program pays off: the same records you kept for security become the evidence that makes an audit routine.

It draws on everything before it — the right events (what to log), preserved off-box (centralizing logs), and made trustworthy (tamper-resistant trails). It is the closing article of the Logging & Audit series.

Decoding What an Evidence Request Really Asks For

The core skill of audit reporting is translation. Auditors, lawyers, partners, and regulators do not speak in log fields; they speak in outcomes and obligations. Your job is to hear the business question and map it onto the logs. The request sounds abstract; the answer is always some combination of who, what, when, from where, and what happened — the same fields you have been capturing all along.

A few common requests, translated:

• "Show me all access to [sensitive data] during [period]." This is really: every operation touching a particular path or folder, between two dates, with the account and source for each. It is an access-to-path question.
• "Prove that partner X received (or sent) the expected files." This is: every transfer to or from that partner's account in the period, with filenames, sizes, and outcomes — ideally corroborated by a delivery receipt. It is a partner-activity question, and where a structured receipt exists, such as an AS2 MDN, it is the strongest possible corroboration, as covered in MDN proof of delivery.
• "Who had access to, or acted on, this system?" This splits in two: the authentication record (who logged in, from where, successfully or not) and the administrative record (who changed accounts, permissions, or configuration). It is an authentication-summary plus admin-changes question.
• "Demonstrate that former employee Y no longer has access, and show their last activity." This is: that account's final sessions, and confirmation of its disablement in the admin log. A by-account question with a specific end.
• "Show that failed and unauthorised attempts are detected and handled." This is: blocked logins, lockouts, and policy denials over the period — proof your defences are both present and observed.

The pattern is always the same: strip the compliance language, find the who/what/when/where underneath, and you have a query. Do this a few times and you notice that the same handful of shapes recur — which is exactly why you build them once.

The Canned Reports Worth Building Once

A canned report is a saved, parameterised query you build carefully one time and then run on demand by filling in a date range or an account name. The investment is small and the return is enormous: instead of reconstructing a query under deadline pressure and hoping it is complete, you run a report you have already validated. The list below covers the great majority of real evidence requests. Build these, name them, and keep them where the team can find them.

CANNED REPORTS  --  build each once, run on demand

REPORT  access-by-account
  answers  "everything account X did between date A and B"
  inputs   account, date range
  columns  time, session, source IP, operation, path, bytes, result

REPORT  access-to-path
  answers  "everyone who touched folder/file P in a period"
  inputs   path, date range
  columns  time, account, source IP, operation, result

REPORT  authentication-summary
  answers  "logins and failures by account and source"
  inputs   date range
  columns  account, source IP, successes, failures, first+last seen

REPORT  admin-changes
  answers  "every account / permission / config change, by whom"
  inputs   date range
  columns  time, actor, change type, target, before -> after

REPORT  partner-activity
  answers  "did partner X send / receive the expected files"
  inputs   partner account, date range
  columns  time, direction, filename, bytes, result

REPORT  transfer-volume
  answers  "what moved in and out, totalled by account + direction"
  inputs   date range
  columns  account, direction, file count, total bytes

REPORT  failed-and-denied
  answers  "blocked logins, lockouts, and policy denials"
  inputs   date range
  columns  time, account, source IP, reason

Two habits make these reports far more useful. First, have every report carry a small header stating what it is, the exact time range, the source of the data, and when and by whom it was generated — an auditor's first questions, answered before they ask. Second, build each report to run against your central collector, not an individual server, so one report covers the whole estate and cannot miss a box you forgot about. The reports are only as complete as the logs behind them, which is why centralizing came first.

The mapping from request to report is worth keeping visible, because it is what lets anyone on the team answer a request without deep log expertise. Once the reports exist, responding is a lookup, not a research project.

A Request, Start to Finish

To see the pieces work together, follow one real-shaped request from arrival to delivery. The email reads: "A contractor left at the end of March. Show their last activity, and prove their access was removed and not used afterward." It sounds like a research project. With the canned reports, it is fifteen minutes.

First, translate. This is two questions wearing one coat: what did the account do near the end, and was it disabled and then genuinely inactive? The first is an access-by-account question; the second is an admin-changes question plus a check that nothing follows.

Then run. Execute access-by-account for the contractor's account over March and April. The report shows their normal transfers through late March, then nothing after the 31st — the absence is itself part of the answer. Run admin-changes filtered to that account, and there is the line that matters: on March 31 at 17:40, administrator jordan disabled the account, with the before-and-after state recorded. Run failed-and-denied for the same account across April, and any attempt to use the dead credential would appear as a denial, proving the lock held.

Finally, assemble. Put the three reports together, each with its header stating the time range, the source collector, and when it was generated. Add one sentence of narrative — "account active until March 31, disabled by jordan at 17:40 that day, no successful access thereafter" — and the evidence is complete, corroborated, and self-explanatory. Because the underlying logs were forwarded off-box and are append-only, you can also answer the follow-up you know is coming: yes, this is the whole record, and here is why it could not have been trimmed.

Retention Policy That Makes Audits Painless

A perfect report is useless if the data rolled off last month. The quiet foundation of audit-ready reporting is a retention policy: a written statement of what you keep, for how long, where, and who can touch it. It resolves the tension from earlier in the series — keep logs long enough to answer late questions, but not so long that you hoard personal data you cannot justify — and it turns retention from an accident into a decision you can show an auditor.

Here is a template. Fill the blanks with values that match your obligations, get it agreed, and keep it beside the reports.

LOG RETENTION POLICY  --  template (fill the blanks)

Scope:            transfer activity logs + their forwarded copies
Owner:            __________  (a role, not a named person)
Where kept:       central collector; archive on __________
Hot / searchable: __ days     (fast investigation + reporting)
Archive:          __ months    (compressed, restricted access)
Total retention:  __ (maximum) -- deleted after this, verifiably
Legal hold:       overrides deletion when invoked by __________
Access:           read:  __________
                  delete: __________  (restricted + itself logged)
Integrity:        forwarded off-box; append-only; __________
Privacy:          no secrets or file contents logged;
                  personal data minimised to what is needed
Review:           this policy reviewed every __ months

Three lines in that template do the heavy lifting at audit time. Total retention proves you keep evidence long enough and delete it on purpose — both of which auditors ask about. Legal hold is the escape hatch that pauses deletion when a dispute or investigation is live, so nothing relevant disappears on schedule at the worst moment. And access shows that the record is controlled, which is what makes a report credible rather than merely produced.

Making Reports Credible, Not Just Available

A report is a claim, and a claim is only as strong as the trail behind it. An auditor who cares will ask the obvious follow-up: how do I know this report is complete and unaltered? Your answer comes straight from the tamper-resistance work. The logs were forwarded off-box in real time, so they could not be quietly edited on a compromised server; the trail is append-only and, where you went further, hash-chained, so alteration would be detectable; duties are separated, so the person who ran the transfers is not the person who could have doctored the record; and every machine shares a synchronised clock, so the timestamps in the report actually line up. A report backed by those properties is evidence. The same report pulled from a single editable file on the server it describes is just a printout.

Completeness deserves its own mention, because it is the follow-up auditors reach for once integrity is settled: how do you know nothing is missing from the period? Here the silence-monitoring from centralizing pays a second dividend. If you can show the collector received an unbroken stream from every server across the reported window — no gaps where a source went quiet unnoticed — you are demonstrating not just that the lines you have are genuine, but that there are no lines you are quietly lacking. A report over a period with a documented, gap-free feed is far stronger than the same report over a period where logging might have lapsed and no one would know.

This is why the series is ordered the way it is. Reporting is the visible top of a stack: the credibility a report needs at audit time was built months earlier by logging the right things, getting them off the box, and making them tamper-resistant. When someone asks "can you trust this?", the honest, confident yes is assembled from all of it, and the deeper foundations of that trust — signatures, timestamps, and independent receipts — live in the signatures and non-repudiation pillar.

Match the Report to the Audience

The same underlying data serves several audiences, but each wants it framed differently, and reading the audience saves everyone time. Four recur:

• Internal review wants summaries and trends — the authentication and volume reports at a glance, to spot drift and confirm things look normal. Detail on demand, not by default.
• External auditors want completeness and integrity above all. Give them the scoped detailed reports with their headers, and be ready to explain the trail that makes them trustworthy. Their job is to doubt, so answer the doubt before it is raised.
• A partner in a dispute wants one transaction, precisely: did this specific file arrive, when, intact? The partner-activity report narrowed to the transfer in question, ideally beside an independent delivery receipt, settles most disputes quickly and without acrimony.
• Legal or an investigation wants a narrative evidence pack: the relevant logs, hashes, and receipts assembled into a documented, chain-of-custody account that holds together months later. This is the heaviest form, and the receipts-and-signatures habits in the proof-of-delivery material are what make it possible.

Knowing which of these you are serving tells you how much to send. Over-sending a legal-grade pack to a partner who asked a simple question wastes effort and scatters sensitive data; under-sending a summary to an auditor who wanted detail just means doing it twice. Match the shape to the ask.

Self-Service, Scheduling, and Cadence

The final step is to stop treating audits as events and start treating reporting as routine. The shift is mostly one of mindset: a team that reports only when asked is always starting cold, while a team that reports on a rhythm always has the answer half-written. There is a quiet second benefit, too — the reports you generate on a schedule become dated artifacts in their own right, a running history you can retain alongside the raw logs, so "what did last March's authentication summary look like" is itself already answered. A few practices get you there:

• Schedule the standing reports. Run the authentication summary, admin-changes, and transfer-volume reports on a regular cadence — monthly, say — and keep the output. When an auditor asks for last quarter, you already have three months of it filed, not a scramble ahead of you.
• Give auditors scoped, read-only access. Where you can, let reviewers run the canned reports themselves against a read-only, time-boxed view, rather than emailing spreadsheets around. Self-service is faster for them, less work for you, and avoids scattering copies of sensitive logs across inboxes.
• Keep a short evidence index. A one-page list of which reports exist, what each answers, where the retention policy lives, and how to run them turns audit response from tribal knowledge into a task anyone on the team can do.
• Review after each audit. Whatever the auditor asked for that you did not already have a report for becomes the next report you build. Over a couple of cycles, your canned set converges on exactly what your auditors actually want.

All of this assumes the underlying service emits complete, well-structured activity records in the first place — the raw material every report is made from. A server such as Sysax Multi Server records activity across FTP, FTPS, SFTP, and HTTPS in one place, which is the kind of consistent source that makes a single access-by-account or access-to-path report cover every protocol a partner might have used, rather than forcing you to reconcile three different formats by hand.

Where This Leaves You

Audit-ready reporting is preparation, not heroics. Learn to translate an evidence request into a who/what/when/where query; build the small set of canned reports once, validated on a calm day and run on demand; set a written retention policy so the data is always there, with a legal-hold escape hatch and controlled access; and lean on your tamper-resistance work so every report is credible, not merely available. Do that, and the next audit is a morning's work of running reports you already trust — not a week of screenshots and second-guessing.

That closes the loop this series began. If you are arriving here first, start at what a transfer service should log and work forward; the reports here are only as good as the logging, centralization, and integrity beneath them. To make the evidence itself unimpeachable, pair this with making audit trails tamper-resistant, and to catch problems long before they reach an audit, with alerts worth raising from transfer logs.

Frequently Asked Questions