Secure Cloud SFTP for FERPA: Access Controls, Audit Logs, Encryption, Key Management

A FERPA scenario: the transfer that “worked” until review day

A school district sends a nightly enrollment export to an edtech vendor. A university shares a batch of academic transcripts, admissions files, enrollment records, financial aid applications or tuition payment records with a partner. A special education team uploads evaluation documents for a contractor.

Everything goes through and everyone moves on. Then a parent inquiry, internal audit, or contract review lands and asks a basic question: who received the data, and who actually accessed it?

That’s where most FERPA file workflows stumble. The transfer succeeds, but the story you need later is missing.

There’s no such thing as a “FERPA certification,” and no tool can magically make an institution compliant. FERPA compliance is owned by the institution through the way it drafts, maintains and follows policy, contracts, permissions, training, and everyday habits.

What FERPA applies to in everyday file workflows

FERPA applies to education records and personally identifiable information in those records. If your team handles education records, you’re already in FERPA territory, even if the work feels routine and non-sensitive.

In real life, FERPA territory can mean:

• Transcript exports and enrollment feeds.
• Special education documentation and evaluations.
• Admissions, advising, student services, and financial aid files.
• Vendor data drops, imports, and ongoing integrations.

Secure file transfer, secure file sharing, and secure cloud storage become risky when they create extra copies, unclear recipients, or uncontrolled re-sharing. The risk isn’t always about someone “hacking in”. Sometimes it just boils down to nobody knowing what happened, and no proof of events.

Where secure cloud SFTP fits

Secure cloud SFTP and storage solutions like SFTP To Go come in handy when K-12 teams, school districts, higher education, and universities need repeatable secure, compliant file transfer between systems or organizations.

A comprehensive managed cloud transfer solution will facilitate rules around who can connect, what they can access, and what gets logged, actively encouraging compliant behaviors throughout a streamlined and lean UX. Otherwise, and this happens readily with self-hosted SFTP or some of the more old-school MFT solutions, you’ve just built a faster way to lose track of disclosures.

Recordkeeping and disclosure trails: how the trail gets lost at times

FERPA’s recordkeeping requirement is plain in the regulations. Schools are expected to keep a record of requests for access to, and disclosures of, personally identifiable information from education records, with defined exceptions (see 34 CFR 99.32), for as long as the education records themselves are kept.

In file workflows, the trail usually breaks because teams lean on tools that weren’t built to answer “who accessed what” later, email being a prime culprit here. But there’s a long list of culprits, and chances are your team uses a few of them! The audit trail for emails is vague at best. Read this to know more about the drawbacks of email attachments for regulated workflows.

Common ways the trail disappears:

• A file is sent from email, and the only “record” is an inbox thread.
• A shared drive link is forwarded, and access changes aren’t reviewed.
• A “temporary export” becomes a long-lived copy in multiple locations with recipients unknown.
• A vendor account stays active long after the work ends.

FERPA questions often arrive well after the transfer, that’s why solid procedure and habit are so essential. If your only evidence is “I sent it on Tuesday, I think,” you’re stuck guessing who accessed the file and when. 

Vendors, the “school official” exception, and direct control

FERPA allows certain disclosures without consent under specific conditions, including disclosures to “school officials” with legitimate educational interests (see 34 CFR 99.31). Student Privacy guidance also explains that contractors can sometimes be treated as school officials when requirements are met.

One phrase matters a lot in real operations: direct control. This is all about what you can actually enforce when vendor access is live.

What direct control means in file access terms

In practice, direct control means:

• Vendor access is tied to a named login or credential, not a shared account.
• Vendor access is limited to only the folders required for the service.
• Vendor access can be removed quickly when the purpose ends.
• The school can review activity to confirm that access stayed within what was intended.

This is the point where student data privacy moves from theoretical to measurable.

Access controls that actually work

Access controls fail when they’re designed for convenience and speed first and accountability later. FERPA-facing workflows need controls that keep working even when staff change, vendors rotate, and someone asks for a “quick share.”

Use named access, not shared access

Named access, with stringent access controls, is a great way to enforce accountability. If a vendor or staff member has their own access, you can remove it cleanly and you can review what happened. SFTP To Go facilitates all this through a combination of configurable access controls, name and folder specific credential provisioning, webhooks for real-time file-event notifications, and logs with log histories for compliant oversight of who did what and when!

Shared credentials and shared links blur responsibility, and they turn a simple question into a messy investigation that will shine a poor light on you.

Limit access by folder and permission

Least privilege is easier when you limit where a user can go and what they can do, what folders and files they can access, how they can interact, and for how long. Give upload-only access to an intake folder when a vendor only needs to deliver files. Give read-only access when a party should never delete or overwrite content.

Make offboarding routine

Offboarding should be normal, quick, and repeatable. If removing access is painful, it will get delayed, and delayed offboarding becomes “permanent access by accident.”

Audit logs as your FERPA proof

FERPA recordkeeping isn’t the same thing as a technical audit log, but audit logs often help support FERPA compliance because they answer the questions that come up during reviews. “Did anyone download this?” “Did they share access with anyone else?” If you’ve shrugged in response to either, well, that is not ideal.

NIST SP 800-92 is an apt computer security framework that lays out why security logging exists in the first place: accountability, investigation, and evidence when something needs to be explained. It will do you and your team good to know and implement the standards it presents.

What your logs need to capture

For education record disclosures and access review, audit logs are most useful when they capture at least:

• Successful and failed logins.
• Upload, download, delete, and denied access events.
• The actor identity tied to each event.
• Time, IP address, and client details when available.

If you use secure file sharing links, link access outcomes matter too, because they show whether a link was used, expired, or rejected.

Why exportable logs matter

Logs that stay trapped in a UI are harder to retain and harder to connect to broader compliance evidence. Exportable audit logs can support retention, internal audits, and faster response when someone asks what happened to a specific file.

Encryption and key management that’s enforced and consistent

Encryption helps reduce exposure, but it doesn’t solve uncontrolled access or missing disclosure records. It’s one part of a FERPA-aligned system, but not the whole shebang.

Encryption in transit vs encryption at rest

Encryption in transit protects data while it moves between systems. HTTPS, SFTP and FTPS are highly secure transfer protocols designed to encrypt the session from A to B and back again.

Encryption at rest protects stored data. It helps reduce exposure if the storage backend is compromised, alongside access controls. For example, SFTP To Go uses Amazon S3 with encryption at rest, but it doesn’t prevent an authorized user from downloading and re-sharing data.

If your risk model includes “the file might be copied after download,” you may also need file-level encryption on top of transport encryption, depending on the workflow, so check out our guide on how to select your encryption methods.

SSH key management: where automation can go wrong

SSH keys are widely used for automated secure file transfer. They can also become long-lived access paths if nobody owns them and they never get rotated.

NIST IR 7966 highlights common SSH key management problems such as unknown key ownership, unused keys that remain valid, and weak lifecycle practices. These issues, described in the NIST language, trickle into a range of other frameworks that oversee data management controls through various regulated sectors, FERPA being one of them, so pay attention to them as well. 

Practical rules that hold up:

• Keep private keys only on the systems that run the transfers.
• Use a unique key pair per integration so you can remove one vendor without breaking others.
• Rotate keys on a schedule, and remove keys immediately when access should end.

How SFTP To Go supports FERPA-focused secure cloud SFTP workflows

SFTP To Go is not going to magically make you FERPA compliant. What it will do is fully support FERPA compliance by providing the requisite technical controls that make controlled transfer, controlled sharing, and reviewable access wholly practical and streamlined.

SFTP To Go will facilitate: 

Separate admin dashboard access from storage access

SFTP To Go offers two login types: Accounts (for the admin dashboard) and Credentials (for folder/file access over supported protocols). This separation keeps vendor, partner, and employee transfer access away from admin controls and sensitive data.

Folder-based access and clear permission options

SFTP To Go credentials are assigned permissions and a home directory that limits where they can access files. This supports access that’s limited to a specific folder path rather than broad storage access.

Multi-factor authentication and web access controls

SFTP To Go lets you set a password policy for credentials, and choose which multi-factor authentication factors are available for web portal sign-ins. Dashboard users can also enable MFA in their account settings, and organization admins can monitor who has MFA enabled.

Secure protocols and encryption basics

SFTP To Go is built for secure protocol-based access, including HTTPS, SFTP and FTPS. It includes encryption at rest on built-in Amazon S3 storage using server-side AES-256. Watch this for a full review of SFTP cloud storage.

SSH key authentication features you can actually operate

SFTP To Go supports SSH key authentication for SFTP, including accepted key types and the ability to add and remove public keys on a credential. It also supports an organization-level setting to require public key authentication.

IP-based connection restrictions

SFTP To Go allows for inbound network rules that can restrict access to specific IP address ranges, depending on plan. This can help reduce vendor access to known networks when an integration has predictable source IPs.

Audit logs that can be exported into storage

SFTP To Go creates audit logs that track file and login activity, including specific event types. It also lets you export audit logs to CSV files saved under /audit-logs in your storage. It also supports API-triggered exports and webhook-based notifications when new audit log files appear.

Practical FERPA checklist: a quick implementation plan

• Write a short internal rule that defines which file categories are treated as education records for your workflows.
• Require named vendor (and potentially partner or employee, all referred to hereafter as “user”) credentials, and ban shared vendor logins for secure file transfer.
• Put every user into a dedicated folder path, and avoid giving access to parent folders by default.
• Use write-only intake folders for users that only deliver files, and use read-only access when users should never delete.
• Make access removal part of offboarding, and document who is responsible for removing user access on contract or cycle end.
• Turn on audit log export to CSV and store those exports with other compliance evidence.
• Review audit logs on a schedule, and document what counts as unusual activity for your environment.
• Use unique SSH keys per integration, and keep a simple key register that names the owner, purpose, and rotation date.
• Restrict connections by IP range when your vendor integrations run from known networks.

And so…

FERPA compliance lives or dies on basic operational questions. Who had access? What did they access? When did they access it? If those answers depend on inbox archaeology and memory, the workflow is sloppy.

If you want to tighten controlled transfers and secure file sharing for student data privacy, start with SFTP To Go, then line it up with your policies and vendor agreements via a few simple configuration steps. And there you have it!