SFTP Audit Logs for Compliance: What Auditors Actually Want

There is a gap between a server that logs and a server that produces audit evidence, and it usually surfaces under a specific request. An auditor asks for six months of file transfer records covering one vendor account, and the log directory turns out to hold rotated text files in which one line looks much like the next: the account is shared between three upstream systems so no line identifies a person, and sessions are recorded while the files moved inside them are not.

An audit trail is a narrower thing than a log. It has a specific set of attributes an auditor will test, and a server can log heavily while providing few of them.

What "audit log" means in a compliance context

A file transfer server's logging answers three quite different questions, and it helps to keep them apart even where a server writes more than one of them to the same place.

Diagnostics are for working out why a connection failed. The output is verbose, it sits at whatever level the last engineer to troubleshoot a problem left it at, and its content changes between releases because it is written for developers. In CompleteFTP it goes to Diagnostics.log, and the guide is explicit that raising its level to Debug or All produces a large volume of output and a measurable performance cost.

Operational logging is what people watch day to day, covering service starts, errors, connection counts and the general health of the box. In CompleteFTP this is not a separate file from the diagnostic output: they are one activity log at different severity levels, with the everyday operational view sitting at the Info level and the verbose diagnostic detail appearing only when the level is raised.

The audit log is the one that answers questions about users, recording that a named account performed a named action on a named object at a named time, with the outcome. It is deliberately narrow, its format is stable enough to parse (CompleteFTP can write it as CSV, which imports cleanly into a spreadsheet or database), and it is retained on a schedule that somebody has written down. CompleteFTP keeps it apart from the activity log in Audit.log, rolled daily, with older days retained as Audit.log.YYYYMMDD. A narrower record again, the configuration log, captures the changes an administrator makes to the server itself; in CompleteFTP that is the Config log, and it answers "who changed this setting". An auditor who asks for your logs usually means the audit log.

The seven things auditors actually look for

Audit tests on file transfer are usually specific rather than general, in that somebody names a date, an account and a file and asks you to produce the record. Whether you can depends on seven attributes of what you captured.

Who performed the action

The record has to resolve to an identity, and an IP address is not an identity. This finding comes up more than any other, and it usually has nothing to do with the logging configuration. It happens because the transfers run under a shared service account that three systems and four people all use, so every line in the log says svc_transfer and no line says who was behind it.

Fixing that is an account design problem rather than a logging problem, and one account per counterparty, per system and per person is the only arrangement in which the log can answer the question. Where a shared account cannot be split, auditors will look for a compensating control, typically restricting the account by source IP and by folder so the population of possible actors is small and documented.

What was acted on

The record needs the operation and the object: upload, download, delete, rename, and the full path of the file involved. Session-level logging that shows a login, a duration and a byte count tells an auditor that something happened without telling them what.

Whether data left the organisation is answered by download records, whereas whether a record was destroyed or hidden is answered by deletes and renames. Not every logging configuration records the second kind.

When it happened

A timestamp you can place unambiguously on a timeline, on a server whose clock is synchronised to a known source. Many servers, CompleteFTP among them, record the time without an explicit timezone in each line, so the server's own timezone has to be known and documented for the times to be read correctly. Correlating a file transfer against a VPN log, a badge reader and an application log is the ordinary shape of an incident investigation, and it falls apart when one source is an hour out or stamped in local time across a daylight saving boundary.

Where it came from and where it went

The client IP address, and the destination folder within the server's file system. Access control is usually expressed per folder, so an auditor comparing your stated permission model against actual activity needs paths to compare against.

How the session was established

Protocol, port or site, and authentication method. A record showing that an account authenticated with a password when your policy says that account is key-only is a control failure that only surfaces if the log captured the method.

Negotiated cryptographic parameters belong here too, and interest in capturing them is recent enough that customers ask how it works. One organization asked about the capability as soon as it appeared in the release notes:

"Reading through the release notes of version 25.0.6, I noticed this: 'Add audit logging of SSH connection parameters (including ciphers) to login events.' Please can you explain a bit more about this new feature? Are you able to provide an example of how to use it and what the logging would look like?"
a UK insurance organization (EnterpriseDT support archive)

Recording the negotiated cipher at login is what connects an audit trail to the algorithm policy described in hardening SSH and TLS ciphers.

Whether it succeeded

Successes and failures both belong in the trail, with a reason attached to failures. Failed authentications are the raw material for detecting credential stuffing and for showing that lockout controls work, and failed transfers reconcile the partner who insists a file was delivered against the server that recorded a permission denial. CompleteFTP's reporting layer treats successes and failures as distinct countable fields, which makes "failed logins by account over the last thirty days" a report you can build rather than a text-processing exercise.

Whether the record can be altered

The last attribute is the one that turns a log into evidence. If the audit log lives on the file transfer server in a directory writable by that server's administrators, then the people with the strongest motive to edit it also have the ability. Auditors phrase this as segregation of duties, and the accepted answer is that a copy leaves the machine promptly and lands somewhere the file transfer administrators do not control, usually a SIEM, a log collector or write-once storage. None of this happens on its own: on CompleteFTP you make it happen either by adding a forwarding appender to the logging configuration or by scheduling a task that copies the rolled audit files off the box, both shown below.

What OpenSSH on Windows actually logs

OpenSSH's logging is honest about what it is, which is diagnostic output from a daemon rather than an audit trail. On Windows builds, sshd writes to the Windows Event Log under its own OpenSSH channels, and on Linux it goes to syslog or the systemd journal. At default settings you get authentication events, including which key or password method succeeded, the source address, and session open and close. Connection-level questions are answerable from that.

File-level activity is where the gap sits. The SFTP subsystem handles the actual file operations, and at stock settings those operations are not individually recorded. Running the subsystem with its logging level raised produces per-file entries for opens, closes, renames and removes, which is a one-line change to sshd_config and worth making on any OpenSSH host that carries regulated data.

Three characteristics remain after you have done it. The output is free text intended for humans, so anything downstream is parsing prose rather than reading fields, and the prose can change between OpenSSH releases. Retention is whatever the platform's log rotation happens to be set to rather than a period chosen for compliance reasons. The records also sit in files owned by the operating system on the same host, so tamper resistance is unaddressed until you forward them somewhere.

Plenty of regulated environments run OpenSSH with the subsystem logging turned up and a forwarder shipping to a SIEM. Teams usually move on once the audit questions become routine rather than annual, when parsing text files by hand for each one stops being practical.

What CompleteFTP's audit logging captures

Audit logging in CompleteFTP is a feature of the Professional and Enterprise MFT editions. The Standard and Free editions do not include it, which is worth checking before a purchase is signed off on the strength of a compliance requirement.

Once enabled, the server records file transfer operations along with logins and logouts, to Audit.log in the CompleteFTP logs directory, rolled daily with each previous day preserved as Audit.log.YYYYMMDD.

The fields behind an audit event

The clearest view of what an audit event contains comes from the reporting feature, which is built on the audit data. The fields available to a report are the fields the audit trail carries:

Field What it records
Site The site on which the event occurred, for servers running more than one
User-name The account being accessed
IP Address The remote client's address
Path The file path being accessed
Protocol FTPS, SFTP, HTTPS and so on
Event The type of operation
Bytes Volume transferred during the event
Year, Month, Day, Hour, Minute The event time, groupable into a hierarchy
Successes / Failures Counts of successful and failed events

Set against the seven attributes above, that covers who, what, when, where, how and outcome. Tamper resistance is the one attribute no server can supply from within itself. The exact on-disk layout of a line in Audit.log is worth confirming against a file from your own server before you write parsing rules against it.

Granularity by user, folder and action

Because permissions in CompleteFTP are expressed per folder and per user or group, the audit trail lines up with the access control model rather than cutting across it. An auditor asking "show me everyone who touched the payments folder in March" is asking a question with the same shape as the permission grant that allowed it, and the reporting layer will filter on path, on account and on date range in one view.

Reporting is a Professional-edition-and-up feature, enabled separately from auditing; enabling it imports existing audit files into a queryable store, which can take a few minutes where a long history has accumulated. Designing your own reports rather than using the supplied ones is an Enterprise MFT feature.

Getting the records to a SIEM

CompleteFTP's logging is built on log4net, which is what makes forwarding straightforward. Create a LogConfig.xml file in the server's logs directory, copy the default log4net configuration into it as a base, and add an appender. Keeping the customisation there rather than editing the shipped configuration means an upgrade will not overwrite it.

A RemoteSyslogAppender sends output to a syslog daemon, conventionally on UDP port 514, which most SIEM platforms accept directly:

<appender name="Syslog" type="log4net.Appender.RemoteSyslogAppender">
  <param name="RemoteAddress" value="192.168.1.100" />
  <param name="RemotePort" value="514" />
  <layout type="log4net.Layout.PatternLayout">
    <conversionPattern value="%-5p %d [%t] %c - %m%n" />
  </layout>
</appender>

The appender is then referenced from the root logger alongside the existing Audit and Config appenders, and the CompleteFTP service restarted so the configuration is re-read. An EventLogAppender is available on the same basis where a collector reads the Windows Event Log instead, and a SIEM forwarding agent pointed at the rolled audit files avoids touching the logging configuration at all.

Retention

Retention is configured in the same panel that enables auditing. The number of days of audit files kept on the server is a setting, with "keep forever" among the options, and it should be the number written in your retention policy rather than whatever the field was left at.

Where the retention period is long, keeping every day of audit history on the file transfer server is rarely the best arrangement, because the copies that satisfy the retention requirement then live on the machine whose administrators are in scope. A shorter local window with forwarding to long-term storage is the more common production pattern.

Configuration changes and the administration log

File activity is only half of what an audit covers. The other half is who changed the configuration, since a permission grant made on a Tuesday and revoked on a Wednesday can make a month of file activity look entirely legitimate.

CompleteFTP writes configuration changes to a separate administration log, Config.log, in the logs directory. Entries are chronological and separated by blank lines, each beginning with a timestamp and the server name, carrying details of the change, and ending with the identity of the user who made it, with server-initiated changes attributed to (server). The entities covered include users, groups, group memberships, folders in the virtual file system, sites, site-to-user mappings, web apps and authenticators. Collected alongside Audit.log, it answers what auditors are usually driving at, which is whether the access exercised was the access that had been approved.

Mapping to the frameworks that generate these requests

HIPAA Security Rule, 45 CFR 164.312(b)

The Security Rule's audit controls standard calls for hardware, software or procedural mechanisms that record and examine activity in information systems containing or using electronic protected health information. It is deliberately technology-neutral, naming no protocol, prescribing no log fields and setting no retention period for logs.

Where a file transfer server moves ePHI, auditors commonly treat it as an information system within that standard's scope and ask to see records of which accounts accessed which files, when, and with what outcome. A related documentation standard at 164.316(b)(2)(i) sets a six-year retention period, though that provision concerns the documentation the rule requires rather than audit logs, and the two are routinely confused.

PCI DSS Requirement 10

Requirement 10 covers logging and monitoring of access to system components and cardholder data, and it is the most prescriptive of the frameworks here about log content. It calls for records identifying the user, the type of event, the date and time, whether the attempt succeeded or failed, the origination of the event and the affected data or resource, which maps almost field for field onto the attributes described earlier.

PCI DSS also specifies retention, and has done across versions: twelve months of audit log history, with at least the most recent three months immediately available for analysis. The standard further expects audit logs to be protected from unauthorised modification, which is what makes forwarding to a SIEM or a write-once store the normal answer rather than an optional refinement.

SOX and financial reporting controls

Sarbanes-Oxley itself says nothing about SFTP. Section 404 requires management to assess the effectiveness of internal control over financial reporting, and the IT controls that get tested are derived from a control framework such as COSO or COBIT rather than from the statute.

In practice, a file transfer server carrying financial data into or out of a reporting system is treated as part of the control environment. What gets tested is that transfers into the system are attributable, that changes to who can perform them are approved and recorded, and that the records supporting both are retained for the period covered by the audit.

Evidence requests tend to be more specific than the framework language suggests. One organization forwarded what its auditor wanted, in a SOC engagement (a System and Organization Controls audit, the SOC 2 report a service provider gives its customers) rather than a SOX one:

"Our SOC auditor wants to see: 53: SFTP User Restriction Configuration. Please provide a screenshot of the configuration which shows an SFTP user is locked in their file path. Aside from set home as root, how can I show they are locked in their home?"
a US life insurance organization (EnterpriseDT support archive)

The artefact requested was a screenshot of a configuration setting rather than an extract from a log, which is a different kind of evidence from the transfer records discussed above.

GDPR and the accountability principle

Article 5(2) makes the controller responsible for demonstrating compliance with the principles in Article 5, and Article 32 requires security measures appropriate to the risk. Neither article specifies logging, and no GDPR provision states that file transfers must be logged.

Logging becomes relevant through what accountability implies, since demonstrating that access to personal data was limited to those who should have it requires a record of who accessed it. The Article 33 obligation to notify a supervisory authority of a personal data breach without undue delay, and where feasible within seventy-two hours, is difficult to meet if establishing what was accessed takes longer than the notification window.

Audit findings that come up repeatedly

Logs purged before the retention window. A retention policy says twelve months and the server keeps thirty days, because the retention setting was never changed from its default. Check it against the running configuration rather than against the runbook.

Activity that cannot be attributed to a person. Shared service accounts, covered above. Auditors accept a documented compensating control more readily than an explanation, so where the account cannot be split, write down the restriction that bounds who could have used it.

Logs writable by the administrators being audited. Where the only copy of the audit trail sits in a directory the file transfer administrators control, the trail cannot support any finding involving those administrators.

No record of permission changes. File activity is logged and configuration changes are not, so a review can see what was accessed without seeing whether the access was ever authorised. CompleteFTP's administration log covers this, and collecting it belongs in the arrangement from the start.

Enabling audit logging in CompleteFTP

Turning auditing on is a short job in the Manager (Monitoring panel, Log Files tab, Configure Auditing), and the auditing documentation has the click-by-click steps. Three decisions around it matter more than the mechanics:

  • Retention set to match what your policy states, not left at the default.
  • Forwarding to a SIEM or write-once store, so the record an investigator relies on does not live only on the machine whose administrators it audits. Include Config.log alongside the audit log, so configuration changes are captured with file activity.
  • Whether you enable the queryable reporting view, which imports the audit files into a form you can search by date, account and file.

The step that finds the problems is the last one, and it is worth doing before an auditor does it for you: pick a date, an account and a file, and produce the record from the retained logs without touching the live server. Finding a gap in your own time is considerably cheaper than finding it during an audit.

Frequently asked questions

What should an SFTP audit log capture?

The authenticated account, the action, the full path of the file, a timestamp (read against the server's documented timezone, which the records do not carry themselves), the client IP address, the protocol and authentication method, and the outcome including a reason for failures.

How long should I retain SFTP audit logs?

The period comes from the framework you are audited against and from your own documented policy. PCI DSS specifies twelve months with the most recent three months immediately available, while other regimes leave the period to your risk assessment.

Does OpenSSH have audit logging?

OpenSSH logs authentication and session events through sshd, to the Windows Event Log on Windows and to syslog or the journal elsewhere. Per-file operations are not recorded at default settings, though raising the SFTP subsystem's logging level adds entries for opens, closes, renames and removes.

What do auditors look for in file transfer logs?

A specific record for a specific event, produced from retained logs. They then check that the record ties to a named individual, that retention matches your stated policy, and that the log is held where the administrators in scope cannot silently alter it.

How do I ship SFTP audit logs to a SIEM?

Add a syslog appender to CompleteFTP's log4net configuration in LogConfig.xml and reference it from the root logger, or point a SIEM forwarding agent at the rolled audit files on disk.

Is SFTP audit logging required for HIPAA?

The Security Rule's audit controls standard at 164.312(b) calls for mechanisms that record and examine activity in systems containing ePHI, without naming protocols or log fields. Auditors commonly treat a server carrying ePHI as in scope and ask for access records. Configuring a server well supports that obligation without discharging it, since compliance is a property of an organisation's controls rather than of a product it buys.

Where to go next

Audit logging is available in the Professional and Enterprise MFT editions, and the free trial runs at full Enterprise MFT functionality, so the audit trail, the reporting layer and syslog forwarding can all be exercised against real traffic before anything is purchased. The auditing page in the user guide covers the configuration panel and the logging configuration page covers appenders in detail. For the surrounding decisions, the SFTP server guide covers deployment and operational setup, and the MFT versus SFTP comparison covers the point at which audit and workflow requirements start pointing past a plain SFTP server.

Other technical articles

Download Free Trial