
Disaster Recovery and Ransomware: What You Need to Know
Ransomware continues to be one of the most effective and profitable types of malware in cybersecurity.
A bank asks you to encrypt every outbound file with its PGP key. A healthcare partner sends you an .asc file and a fingerprint to verify. Someone on your team asks, "Isn't SFTP already encrypted?"
All three situations point to the same requirement: protect the file itself, not just the connection carrying it.
PGP encryption turns a readable file into ciphertext that only the intended recipient can unlock. It can also add a digital signature, so the recipient can verify who sent the file and whether it changed along the way.
PGP stands for Pretty Good Privacy, the name of the original software released by Phil Zimmermann in 1991. Today, most organizations use software such as GPG that implements the OpenPGP standard, which is why the same keys are just as often called GPG keys. Yet "PGP" remains the term banks, credit bureaus, healthcare organizations, and other large counterparties use in their security requirements.
The cryptography is well established. The harder problem is making PGP work reliably across dozens of partners, keys, schedules, and automated workflows.
PGP is a form of file-level encryption. It protects the contents of a file before the file is transferred and keeps those contents protected until an authorized recipient decrypts them.
That makes PGP different from transport security. SFTP and TLS encrypt a network connection. PGP encrypts the file itself.
A file sent over SFTP is protected while it moves between two systems, but it may be stored as plaintext after it arrives. A PGP-encrypted file remains unreadable while it sits on an SFTP server, in cloud storage, in a backup, or on an integration platform.
This is why counterparties often require PGP and SFTP together. SFTP protects the connection; PGP protects the file throughout its journey.
PGP begins with a key pair: a public key, which can be shared, and a private key, which must remain secret.
If a partner wants to send you an encrypted file, you give them your public key. They use it to encrypt the file, and you use the corresponding private key to decrypt it.
A useful analogy is an open padlock. You can give copies of that open padlock to anyone. A sender places one on a box and snaps it shut, but only you have the key that opens it.
The real process is slightly more sophisticated.
Public-key cryptography is useful for exchanging secrets, but it is inefficient for encrypting large files. PGP therefore combines two kinds of encryption:
When the recipient opens the file, the process runs in reverse: the recipient's private key decrypts the session key, and the session key decrypts the file.
This approach is called hybrid encryption. It combines the speed of symmetric encryption with the secure key exchange provided by public-key cryptography.
Encryption answers the question, "Who can read this file?" A digital signature answers two different questions: who sent it, and has it changed?
To sign a file, PGP creates a cryptographic hash, a short, content-dependent fingerprint, and produces a signature using the sender's private key. The recipient verifies that signature using the sender's public key.
If the file changes after it is signed, even by a single byte, signature verification fails.
A file can be signed and encrypted in the same operation. Encryption keeps the contents private, and the signature proves the sender's identity and detects changes.
Modern OpenPGP implementations also include integrity protection for encrypted data, so recipients detect tampering or corruption rather than silently accepting altered output.
These terms are closely related, but they do not mean exactly the same thing.
PGP was the original encryption program released in 1991. It is also the name people commonly use for the broader approach to file encryption and digital signatures.
OpenPGP is the open standard based on PGP. It defines interoperable message, key, encryption, and signature formats so different tools can exchange protected files.
RFC 4880 defined the widely deployed version of the standard for many years. It was superseded in 2024 by RFC 9580, which modernized the OpenPGP specification.
GPG, short for GNU Privacy Guard, or GnuPG, is a free, open-source implementation of OpenPGP. It is the command-line tool many businesses use to generate keys, encrypt files, decrypt files, and verify signatures.
In everyday conversation, the terms often blur together. A partner who asks for your "PGP key" generally wants an OpenPGP-compatible public key, and many teams generate that key with GPG.
Keys and files are usually interoperable across compliant tools, although compatibility can depend on which algorithms and OpenPGP features each product supports. The difference between a PGP key and a GPG key is therefore less about the purpose of the key and more about the software and terminology involved.
PGP is most useful when a file must remain protected regardless of how it is transferred or where it is temporarily stored.
The most common reason businesses adopt PGP is simple: a counterparty requires it.
Banks, insurers, asset managers, credit bureaus, healthcare clearinghouses, and other large organizations often require vendors to encrypt outbound files with the partner's public key, decrypt inbound files with their own private key, verify key fingerprints before use, rotate keys on an established schedule, and maintain logs showing which key was used for each operation.
Meeting those requirements is a condition of doing business.
PGP is frequently used for files containing payroll records, insurance claims, healthcare data, financial transactions, settlement records, credit information, and customer or employee data.
Because the file remains encrypted at rest, someone who gains access to the storage location still cannot read it without the appropriate private key.
Business files often pass through several intermediaries: managed file-transfer gateways, cloud storage systems, value-added networks, integration platforms, and partner servers.
Transport encryption protects each individual connection. PGP stays with the file across the entire route.
Software publishers use OpenPGP signatures to let customers verify downloaded packages. Businesses use the same mechanism to sign reports, payment files, or other documents.
A valid signature confirms that the file was signed by the expected key and has not changed since it was signed.
Using SFTP or HTTPS does not make PGP redundant. They protect different layers.
SFTP and TLS encrypt data in transit. They prevent someone monitoring the network from reading the file while it moves between systems.
Once the transfer ends, however, the receiving application may write the file to disk in plaintext. At that point, the file's security depends on server permissions, storage encryption, application controls, and the people who administer the system.
PGP encrypts the file before transfer. It remains encrypted on the sending system, during transit, on an intermediate server, in cloud storage, in backups, and on the receiving system, until an authorized process decrypts it.
The strongest arrangement is to use both controls. A PGP-encrypted file sent over SFTP receives connection-level protection in transit and file-level protection before and after the transfer.
The basic GPG commands are straightforward.
Suppose a partner sends you a public key named brightway-retail.asc. First, import it:
gpg --import brightway-retail.asc
Next, inspect the key's fingerprint:
gpg --fingerprint edi@brightway-retail.example
Do not verify a fingerprint using the same email that delivered the key. Compare it with a fingerprint provided through a separate trusted channel, such as a phone call, secure portal, or previously established contact.
Once the fingerprint is verified, encrypt a file for the partner:
gpg --encrypt \
--recipient edi@brightway-retail.example \
orders.csv
This creates orders.csv.gpg. Only a holder of the matching private key can decrypt it.
To sign and encrypt the file in one step:
gpg --sign \
--encrypt \
--recipient edi@brightway-retail.example \
orders.csv
When an encrypted file arrives, decrypt it using your private key:
gpg --decrypt \
--output remittance.csv \
remittance.csv.gpg
These commands are not the difficult part. The difficulty begins when they must run unattended every night for 20 partners, each with different keys, folders, expiration dates, naming rules, and delivery schedules.
The cryptography is mature. The operational work surrounding it is where most teams struggle.
A private key must be protected from unauthorized access, but an automated process still needs to use it.
In a legacy environment, that often means a keyring stored on one server, a passphrase embedded in a script or configuration file, limited visibility into who can access the key, and a single point of failure if the server becomes unavailable.
The result may work, but it is difficult to secure, audit, and maintain.
Partners frequently set expiration dates and rotation schedules for their keys. Your organization may do the same.
If a key expires before a replacement is installed, an otherwise healthy batch process fails without warning. The resulting error looks like a malformed or corrupted file rather than an expired key, which makes the incident harder to diagnose.
A reliable operation needs advance warnings, documented ownership, overlap periods, and a controlled way to retire old keys.
Public keys are designed to be shared, but they still must be authenticated.
If an attacker can replace a partner's public key with their own, they may be able to intercept files encrypted to that fraudulent key. That is why fingerprints get checked through a separate, trusted channel.
This step is easy to describe and surprisingly easy to mishandle. Partner onboarding often stalls in email threads over which key is current, whether a fingerprint was verified, and who has authority to approve it.
Each partner needs clearly defined keys and workflows. A file intended for one recipient must never be encrypted with another recipient's public key.
With homegrown automation, this separation depends on folder names, scripts, configuration files, and keyring entries all remaining synchronized. A small configuration error routes a file incorrectly or makes it impossible for the intended recipient to decrypt.
Production workflows must do more than encrypt and decrypt. They must also detect incoming files, apply the correct key, handle passphrases securely, move output to the right destination, retry temporary failures, quarantine invalid files, alert the correct team, record which key was used, and preserve an audit trail.
Many scripts handle the happy path. Far fewer provide the monitoring, controls, and evidence that security teams and auditors expect.
PGP encrypts files so their contents remain private across transfers, storage systems, backups, and third-party platforms. Common uses include exchanging payroll, healthcare, financial, insurance, and customer-data files with business partners, and PGP signatures verify a file's origin and detect changes.
Yes, when it is implemented with modern algorithms, current software, appropriate key sizes, and sound operational controls. The most common risks are not failures in the underlying cryptography. They are problems such as stolen private keys, weak passphrase handling, unverified public keys, obsolete algorithms, excessive access, and missed key rotations.
PGP is the original software and the common name for this type of encryption. OpenPGP is the interoperability standard. GPG is a widely used open-source implementation of that standard. In practice, someone asking for a "PGP public key" accepts a compatible key generated by GPG.
GPG keys protect a file at the file level, independent of how it travels. A transfer protocol like SFTP encrypts the tunnel the file moves through; a GPG key encrypts the file itself, so it stays locked before it is sent, while it sits on a server, and after it is delivered. The two layers stack, and the same key pair also signs a file so the recipient can prove it came from you and arrived unchanged.
No. SFTP protects the connection; PGP protects the file. Organizations commonly use them together so files are protected both while moving over the network and while stored on either side of the transfer.
You can generate an OpenPGP key pair with GPG using gpg --full-generate-key. Share the public key with partners, but protect the private key and its passphrase, and verify a partner's fingerprint through a separate trusted channel before using their key. On Files.com, the GPG Key Manager generates or imports keys and stores private-key material in encrypted form.
Yes. Encryption runs automatically before delivery, and decryption runs when a file arrives. A production-ready workflow also manages key selection, rotation, access controls, failure handling, notifications, and audit logging, and those surrounding controls are what make platform-based automation easier to maintain than scripts.
A few GPG commands may be enough for one partner. As the number of partners grows, key management and workflow orchestration quickly become the larger job.
Files.com is the cloud-native File Orchestration Platform: one platform that replaces the stack of legacy tools IT teams run to move files, including SFTP and FTP servers, MFT suites, file-sharing apps, and the custom scripts holding them together. It speaks every protocol, connects 50+ cloud and on-prem systems, automates every transfer, and keeps a complete audit trail.
For PGP, a folder you mark for a partner encrypts every outbound file with that partner's public key and decrypts every inbound file with your private key, whether the file arrives through SFTP, FTPS, HTTPS, the API, a share link, an Inbox, or a Sync. The GPG Key Manager generates or imports keys in the browser, with no third-party software, and stores them encrypted where Files.com staff cannot read them, with no keyring on any individual transfer server. Different folders carry different keys, so partner boundaries are enforced by policy instead of scattered scripts, and recryption decrypts a file with one key and re-encrypts it with another for partner-to-partner delivery.
Files that enter through the Files.com Agent get the same treatment, and every encryption and decryption lands in the audit log with the file, the key, and the actor, ready for the next workflow step.
The larger point is simple: PGP itself is not particularly difficult. Running it reliably, across partners, protocols, keys, and compliance requirements, is the real challenge.
To automate that work without maintaining a collection of GPG scripts and server keyrings, explore Files.com's PGP and GPG encryption or start a free trial, no credit card, live in minutes.

Ransomware continues to be one of the most effective and profitable types of malware in cybersecurity.
Learn what SFTP (SSH) host keys are, how they work, and why they are essential for secure file transfers. Understand key management, verification, and troubleshooting to strengthen your SFTP security posture.

From unsecured links to compliance blind spots, traditional file-sharing methods can leave your business exposed. Here, we break down the hidden dangers lurking in B2B file exchange and show how Files.com helps you eliminate them with built-in security, automation, and total visibility.
4,000+ organizations trust Files.com for mission-critical file operations. Start your free trial now and build your first flow in 60 seconds.
No credit card required • 7-day free trial • Live in minutes