The Proton Blog

What is business resilience? Definition and key strategies

Alanna Alexander — Fri, 31 Jul 2026 16:51:21 GMT

Cyberattacks, supply chain failures, and geopolitical shocks shake otherwise stable businesses every year. How your business responds to the unexpected is what will make it last.

A comprehensive business resilience strategy can see you through disruption, help you recover faster, and adapt to whatever comes next.

This article offers:

A clear definition of business resilience and what threatens it
A business resilience framework you can take to your board
A business resilience strategy you can use to maximize your resilience starting today

What is business resilience?

Business resilience is your organization’s ability to anticipate, withstand, recover from, and adapt to disruption. It protects not just your operations, but your finances, your people, and your reputation.

Businesses today face a range of potential disruptions, including:

Cyberattacks: Proton’s SMB Cybersecurity Report 2026 found that nearly 1 in 4 SMBs were hit by cyberattacks in the previous 12 months
Infrastructure outages: Many businesses now rely on major cloud infrastructure providers to support their critical business tools. When those infrastructures go down (as in the 2025 AWS outage), thousands of businesses feel the impact, particularly those without resilience
Supply-chain disruptions: We saw the consequences of this risk at its height during COVID, and the lifting of lockdowns hasn’t eliminated it: A 2024 report found that nearly 80% of organizations’ supply chains had been disrupted in the last 12 months
Market and geopolitical shocks: In Q4 2024, only 8.3% of CFOs named trade and tariffs as a top concern. By Q1 2025, that share had more than tripled to 30.5%
The evolution of technology and work: The World Economic Forum predicts AI will displace 92 million jobs by 2030, and create 170 million new ones

Why is business resilience important?

The most resilient businesses are able to:

Anticipate disruption. Rather than waiting for a crisis to expose their vulnerabilities, they identify risks in advance.

Withstand disruption. They can take the shock of it, while it’s happening, without catastrophic failure.

Recover from disruption. Resilient businesses minimize costs by rapidly getting back to operational normality.

Adapt to disruption. Returning to the status quo means carrying the same vulnerabilities. Resilient businesses update their operations, strategy, and business model in response to what happens.

Business resilience vs. disaster recovery vs. business continuity

Disaster recovery and business continuity are components of business resilience, covering what happens during and immediately after disruption.

Disaster recovery is about restoring IT infrastructure and operations in the immediate aftermath of a disruption. If a ransomware attack takes your file servers offline, for example, disaster recovery is your IT team rebuilding the servers and restoring data from cloud backup until the system works again.

Business continuity is about keeping your business functionally operational while disaster recovery is in progress. That includes your leadership team deciding how to respond, this decision reaching staff, customers, and possibly regulators, and the practical workarounds that keep things running while your systems are down: phone and paper processes, deadlines still being hit, invoices still going out.

Disaster recovery is about how you recover from disruption; business continuity is about how you withstand it while recovery is underway. Business resilience is the wider capacity that covers both — plus what happens either side of this: your ability to anticipate a disruption and recover quicker as a result, and your ability to adapt afterwards so the same attack doesn’t catch you out a second time.

A four pillar business resilience framework

Before you build a business resilience strategy, you need to know what it should cover. This four-pillar framework reflects where disruption actually hits a business.

Measure your business against these four pillars to understand how resilient you are, then use the strategy below to close the gaps you find.

		Example scenarios	Real-world cases
Operational resilience	Can you keep critical business functions running?	A supplier fails to deliver. A cyberattack locks your team out of critical systems.	M&S’s 2025 ransomware attack knocked out the British retailer’s online ordering for 46 days, wiping an estimated £300 million off annual profit.
Financial resilience	Can you absorb a disruption’s economic impact without threatening your long-term viability?	A major client defaults during a market downturn. A shock to supply drives material costs up sharply.	General Motors cut its 2025 profit guidance after estimating tariffs would add $4–5 billion in costs it hadn’t priced into its original forecast.
People resilience	Can you keep the right people available, safe, and able to work through a disruption?	Your CFO resigns mid-crisis. A function is automated faster than your workforce was prepared for.	In 2022, staffing and scheduling failures forced Southwest Airlines to cancel 16,700 flights. The Department of Transportation fined them a record $140 million.
Reputational resilience	Can you protect and recover stakeholder trust during and after a disruption?	A data breach exposes client records. A supplier’s practices attract negative coverage that reflects on your brand.	TikTok had assured regulators that EU user data wasn’t stored in China, then admitted in 2025 that some had been. This drew a €530 million GDPR fine (one of the largest on record) and compounded TikTok’s global trust problem.

How to build a business resilience strategy

Now you know what your strategy needs to cover. This is where business resilience planning starts.

1. Conduct a risk and dependency audit / assessment

Before you do anything else, you need to audit your exposure across all four pillars.

Operational: Surface infrastructure and vendor dependencies. Where are you single-sourced, and what comms channels depend on cloud infrastructure that could go down?

Financial: Review insurance coverage against your actual risk exposure. Stress-test financials against plausible disruptions before they happen.

People: Identify single-point-of-failure roles and thin coverage. Where does the business depend on one person, or one team with no backup?

Reputational: Assess your current crisis-response readiness. If a breach or scandal broke tomorrow, do you have a communications plan and a spokesperson ready?

2. Define and test your business resilience plan

Using your findings, you now need to put together a business resilience plan (sometimes called a business resilience policy).

Document decision-makers: Establish who has the authority to declare a crisis, reallocate a budget, or approve a public statement.
Identify priority processes: Which functions can’t go down, and which can wait if your resources are stretched?
Map out provisional measures to maintain operations: offsite backups with automated failover, pre-arranged credit facilities so liquidity isn’t a scramble, clear employee safety protocols, and pre-approved messaging with escalation protocols ready before a crisis breaks.
Make sure the right tech is in place to execute the plan: backup communication channels, private and confidential remote access and credential management, and a flexible working infrastructure.
Test the plan before you need to execute it: “War-game” scenarios regularly to expose weaknesses and let the team learn in a safe environment.

3. Assign an owner to each resilience pillar

Resilience fails when it’s treated as one function’s job (usually IT’s) alone. Each resilience pillar needs an owner: accountable for its exposure, responsible for keeping the audit current and the plan’s provisions in place, and ready to act if disruption strikes.

Map named owners to named pillars: your COO for operational, your CFO for financial, your CHRO for people, and legal/comms for reputational.

How Proton supports business resilience

Proton Workspace is a privacy-first business suite. It increases your operational and reputational resilience by:

Protecting your data: Proton Workspace is built on an end-to-end encrypted, zero-knowledge infrastructure, which means not even Proton can access your data. It’s additionally protected by some of the world’s most stringent privacy laws. Plus, Proton Workspace includes a business password manager and VPN to further strengthen data protection.

Helping you recover: In the event of a major cloud infrastructure outage, Proton’s independent infrastructure stays up and your teams can continue to email, use cloud storage, collaborate on documents, and meet via video. You can set up a business continuity plan with Proton so you’re ready to quickly switch over when disruption hits

Even the best business resilience strategy depends on a solid technology foundation to succeed. Proton Workspace is built to strengthen that foundation.

Learn more about business continuity with Proton.

Document management systems explained: features, types, and platforms

Greg Ng — Fri, 31 Jul 2026 16:36:16 GMT

Document management system (DMS) are the software equivalent of an office’s filing cabinet. It’s where your business stores, categorizes, organizes, or secures classified documentation. You probably already have one in place.

It could be Google Drive, SharePoint, or an internal business cloud storage system you created yourself. You could be using it to collect contracts, invoices, bank statements, employee records, or product brochure. But how you manage these documents could also be the reason you face astronomical financial losses, industry penalties, and regulatory action.

Why? Because DMS systems were built to keep your documents in order, not protect the data from the threats that have emerged in recent years.

Here’s what secure document management actually looks like, and why the system you’re using right now may not be providing it.

What is a document management system?

A document management system is any software used as a central repository to store, track, and distribute digital documents. With the right storage practices, a DMS can remove the need for physical paperwork and keeps hard-to-track archived files within reach.

A DMS can help you::

Store and organize files: In a single location where every document that was once scattered in folders, email attachments and physical files is accessible and searchable in one search, regardless of who created it or when.
Track who’s seen or contributed to a file: You can see a structured view of your entire sign-off process to double-check modifications to the document. With permissions and credential management settings you can also limit internal exposure and keep sensitive records contained.
Maintain a defensible audit trail: Pre-defined rules can help you archive or delete documents after defined periods, to help meet compliance standards. You can also track every view, edit, or download to stay accountable to regulators.
Automate approval workflows: Notifications and alerts can route documents through stages of approval requests, sign-off stages and review cycles, so you don’t have to chase people down in person.

The three most common document management systems — and why they don’t protect your data

The three platforms below were built for collaboration and scale, and they deliver both. But businesses should want more from their DMS.

Data breaches happen every day and SMBs are particularly at risk. As many as 25% of SMBs suffered a breach or cyberattack last year. And even if your business isn’t breached, you could fall out of compliance with regulations such as GDPR, HIPAA, or fail audits against standards like ISO 27001 because they mandate proactive data protection. The vulnerability itself is grounds for penalization.

With security in mind, we’re analyzing the platforms many IT managers and CEOs choose by default.

Microsoft SharePoint

Why it’s the office default: SharePoint is deeply embedded in the Microsoft 365 ecosystem, which makes it the path of least resistance for businesses already running Outlook, Teams, or Excel. It handles large volumes of documents, supports granular permission settings, and integrates with the rest of the Microsoft stack without additional configuration. For teams that live in Microsoft 365, it works.

How it introduces security risks: SharePoint’s vulnerabilities are largely structural. It operates under Microsoft’s broad data access model — meaning Microsoft retains the ability to access your stored content for purposes including service delivery, compliance, and law enforcement requests. Encryption is applied, but Microsoft holds the keys. Your documents are protected from outside attackers, but not from the platform itself. SharePoint also has a history of misconfiguration issues: overly permissive sharing settings are easy to set and easy to forget, and internal data sprawl — documents shared across teams with no clear ownership or expiry — is a common compliance failure mode.

What to look for instead: A system where the vendor cannot access your content by design — not by policy. Look for end-to-end encryption with keys you control, clear data residency commitments, and sharing settings that default to least privilege rather than open access.

Google Drive

Why it’s the office default: Google Drive is the default choice for businesses already in the Google ecosystem — Gmail, Docs, Sheets, Meet. It’s fast to set up, requires no IT overhead, and its real-time collaboration features are genuinely best-in-class. For small teams that need to move quickly, it gets the job done.

How it introduces security risks: Google’s business model is built on data. Even under a Google Workspace agreement, Google retains broad rights to process your content — for service improvement, ad infrastructure, and compliance with legal requests. Like SharePoint, encryption is standard, but Google holds the keys. There’s also the question of sprawl: Drive makes it frictionless to share documents externally, which means sensitive files can quietly end up accessible to anyone with a link, often without the original owner realizing it.

What to look for instead: A platform that treats your documents as yours — not as data to be processed. Zero-access encryption, where the vendor cannot read your files under any circumstances, and external sharing controls that require deliberate action rather than a single click.

Dropbox

Why it’s the office default: Dropbox built its reputation on simplicity. It syncs files instantly across devices, plays well with third-party tools, and has a low learning curve that makes it popular with smaller teams and freelancers. For straightforward file storage and sharing, it’s hard to fault on usability.

How it introduces security risks: Dropbox encrypts files in transit and at rest — but, again, holds the encryption keys itself. That means Dropbox employees, and by extension government requests, can access your content. It also has a notable breach history: a 2012 incident exposed 68 million user credentials, and the platform has faced criticism for how long it took to disclose the scale of that breach. For businesses handling regulated data, Dropbox’s compliance coverage is also thinner than enterprise alternatives, which can create gaps against GDPR or HIPAA requirements.

What to look for instead: Storage built for cybersecurity compliance from the ground up — with end-to-end encryption, documented data residency, and a vendor whose architecture makes access to your files technically impossible, not just contractually prohibited.

What secure document management actually looks like

The three platforms above aren’t insecure by accident. They were built for collaboration and scale, and they deliver both. Security wasn’t the problem those providers were solving for.

If data security is a priority for your business, these are the features that separate a genuinely secure DMS from one that just looks the part.

Zero-knowledge encryption: Your DMS should encrypt your documents before they leave your device. That means the vendor never has access to your content — not for service delivery, not in response to legal requests. If the vendor holds the encryption keys, you’re trusting their policy. If they can’t hold them by design, you don’t have to.
Open-source architecture and independent audits: Security claims are easy to make. Look for vendors whose architecture is open source — meaning anyone can inspect it — and whose security posture is verified by independent third-party audits, not just internal assertions.
Recognized compliance certifications: ISO 27001, SOC 2 Type II, and HIPAA certification aren’t just checkboxes. They’re evidence that a vendor’s security controls have been tested against an external standard. If you operate in a regulated industry, these aren’t optional.
Jurisdiction and data residency: Where your vendor is headquartered determines which governments can compel access to your data. US-based platforms fall under the CLOUD Act. Make sure you know whose laws govern your documents — and whether that’s acceptable for your business.
Privacy-safe AI: If your DMS includes AI features, confirm that the AI operates without visibility into your document contents — and that your data isn’t used to train the underlying model.

Choosing a DMS that actually protects your data

The document management system you pick determines who can see your business’s most sensitive files for as long as you retain them. Proton Workspace pairs secure document storage with team collaboration tools, so your business gets the collaboration features you need without handing a vendor the keys to your data.

How to create a contingency plan that protects your business

Greg Ng — Fri, 31 Jul 2026 16:21:39 GMT

Even the best project plan can be disrupted by events you didn’t see coming, such as a key team member leaving, a vendor failing, or a platform changing its policies. You can’t control every risk, but you can control how prepared your business is when something goes wrong.

A contingency plan is your documented fallback. It outlines who does what, when, and how if a specific risk happens. Instead of scrambling to make decisions in the moment, your team has a clear plan to follow so work can keep moving.

In this guide, we’ll cover why contingency plans matter, what every plan should include, how to build one step by step, and the mistakes that can undermine them.

Why contingency plans matter for businesses

Let’s think about fire evacuation plans for a moment. Every building, including your office and home, has one, and on a normal day, it just blends into the background. But if a fire does break out, the difference between a team that knows exactly where to go and one that doesn’t is significant. Contingency plans work the same way. They don’t prevent the problem, but they determine how well you handle it.

Consider what happens during a data breach. It’s going to cause damage regardless, but without a contingency plan, your team burns critical time figuring out who’s leading the response, how to notify affected clients, and what systems to prioritize. That delay is what turns a serious incident into a prolonged crisis, because every hour without a coordinated response gives the damage more room to escalate.

The same applies to less dramatic but still disruptive risks, like an unexpected policy change on a key platform, which could force your team to rework a deliverable from scratch to stay compliant. Contingency plans don’t eliminate these risks. But they give your team a clear path forward when a risk materializes, enabling faster recovery, less financial exposure, and stronger client confidence.

Step-by-step guide to create a contingency plan

A strong contingency plan has five core components. Here’s how to work through each one.

Step 1: Identify and prioritize your risks

Start by mapping the specific risks that could disrupt your projects or operations, such as cybersecurity incidents, vendor failures, or regulatory shifts. Assess what each would mean for your business so you can prioritize which risks require the most detailed contingency plans and which your business could absorb with minimal disruption.

Step 2: Set your trigger conditions

Every contingency plan needs a clear activation point. Define what specific event or threshold triggers the plan. For example, if your primary cloud provider experiences more than 4 hours of downtime, you switch to the backup environment. Without defined triggers, your team won’t know when to act, and hesitation increases costs.

Step 3: Document your response actions

Lay out the specific steps your team will follow once the plan is triggered. Keep these concrete and sequential: who does what, in what order, and with what resources. Avoid vague instructions like assess the situation. Keep instructions clear and specific so your team acts as intended.

Step 4: Assign roles and establish communication protocols

Define who is responsible for each part of the response, who has decision-making authority, and who needs to be kept informed. Then, define your communication protocol — which channels you’ll use, how quickly stakeholders need to be notified, and who owns external communications. Good communication keeps the plan in motion and maintains trust with your clients.

Step 5: Test, train, and maintain

Run your team through the contingency plan with tabletop exercises or simulations so the response feels practiced and not improvised. Train new team members as they join, and review your plans regularly to keep them relevant.

How to avoid common contingency plan mistakes

To keep common mistakes from weakening your response during critical moments, build your plan around these best practices:

Tailor plans to specific risks

A data breach and a supply chain attack require completely different responses. Tailor each plan to a specific risk scenario so your team has clear, relevant guidance when they need it.

Make communication part of the plan

A plan can have perfect response actions and still fail if no one knows who to notify, when, or how. Clear communication helps keep the response coordinated during disruptions.

Keep your plans updated

A plan written six months ago might reference tools you’ve replaced or team members who’ve moved on. Review regularly and update after any major operational change.

Plan for worst-case scenarios

Plan for realistic worst-case scenarios, not the optimistic version. Your contingency plan exists for when things don’t resolve quickly or easily.

Use secure tools for better contingency management

Data breaches, unauthorized access, and compromised communications are just some of the notable risks businesses plan contingencies for. Risks arise from vulnerabilities in your email provider’s security model, incomplete encryption on cloud storage, and weak or reused passwords.

Choosing the right workspace matters. End-to-end encryption ensures that even if a breach occurs, the data remains unreadable to anyone who isn’t authorized. Fewer exploitable vulnerabilities mean fewer incidents that trigger your contingency plans in the first place.

Proton Workspace gives your team encrypted collaboration tools for email, calendar, cloud storage, documents, video conferencing, and password management, with end-to-end and zero-access encryption protecting sensitive business data.

Proton is ISO 27001 certified, SOC 2 Type II audited, and supports compliance with frameworks such as GDPR, HIPAA, and CCPA. Based in Switzerland, Proton protects your data under strong Swiss and European privacy laws, helping keep it outside the reach of US surveillance and foreign access requests.

None of this replaces the need for contingency planning. But the fewer fires your team has to fight, the more those plans stay where they belong — in the drawer, ready but unused.

Frequently asked questions about contingency plans

What’s the difference between a contingency plan and a mitigation plan?

A contingency plan is reactive, outlining what you need to do after a specific risk occurs. Mitigation plans focus on reducing the likelihood of that risk happening in the first place, making them proactive. Businesses generally need both to ensure business continuity: mitigation plans to minimize exposure, and contingency plans for when something gets through despite those efforts.

How often should you update a contingency plan?

Review your contingency plan whenever a major change affects your team, tools, vendors, or operations. Plan a review cadence outside of these changes, such as at the start of each quarter, to catch any instructions that might no longer serve your business.

What are some examples of contingency plans?

Some common scenarios businesses build contingency plans for include:

Cybersecurity incidents: Who leads the response, how affected clients are notified, and how systems are isolated and restored.
Key personnel departure: How responsibilities are redistributed, where critical knowledge is documented, and how handovers are managed. To make the offboarding process simpler to manage and more transparent, download our free offboarding checklist templates.
Vendor or supplier failure: Which backup vendors are pre-approved, how to adjust project timelines, and how to communicate delays to clients.
Regulatory or policy changes: How to assess the impact on current projects, who’s responsible for compliance adjustments, and what client communications are needed.

What are email protocols?

Alanna Alexander — Fri, 31 Jul 2026 16:13:38 GMT

We send and receive emails just about every day, rarely thinking about how it works or whether the process is secure. However, choosing the wrong email protocol can cause problems ranging from limited storage space on your computer to data breaches, loss of customer trust, or blocked domains.

This guide outlines how email protocols work, explains the critical difference between functionality and security, and provides a checklist for SMBs.

Email glossary

Email protocols explained

Email security protocols

How protocols impact email marketing success

An email protocol security checklist for SMBs

A quick email glossary

The terminology around emails all sounds very similar, but the distinctions are important. Here’s what we’ll be discussing in this guide:

Email client: The software application you use to read, write, and manage your emails, such as Outlook, Apple Mail, and Proton Mail.

Email protocol: The set of rules that governs how emails are transmitted, received, and stored across the internet. Core protocols like SMTP, IMAP, and POP3 handle the mechanical movement of messages between servers and clients.

Email security protocol: A protective layer of standards that sits on top of core email protocols to ensure privacy and data integrity. These include encryption methods like TLS (for transit) and S/MIME or PGP (for end-to-end content), as well as mechanisms to detect malware or spam.

Email authentication: The process of verifying that an email truly originates from the domain it claims to represent. It relies on the trio of SPF, DKIM, and DMARC to instruct receiving servers on whether to trust, flag, or reject a message, preventing spoofing and phishing.

Email marketing tool: A platform designed to create, send, and track bulk email campaigns, such as Mailchimp, HubSpot, or SendGrid. These tools utilize SMTP to deliver messages and depend heavily on proper email authentication to ensure high deliverability rates.

Email protocols explained

1. Simple Mail Transfer Protocol (SMTP)

What it is: The standard protocol for sending emails. SMTP handles the transfer from your email client to the server, and between servers.

How it works: Your email client connects to an SMTP server, authenticates, and hands off the message. The server then routes it to the recipient’s domain. It’s not possible to send an email without SMTP.

Security note: Standard SMTP sends data in plain text. Without encryption (STARTTLS), sensitive business data can be intercepted.

2. Internet Message Access Protocol (IMAP)

What it is: The modern standard for receiving and managing emails. IMAP keeps messages on the server and syncs them across all your devices.

How it works: When you check your email on your phone, laptop, or tablet, IMAP fetches the latest status from the central server. Because the email is stored on the server, if a laptop is lost, the email history remains safe. Similarly, deleting an email on one device deletes it everywhere.

Security note: Because data resides on the server, strong authentication and encryption are non-negotiable.

3. Post Office Protocol v3 (POP3)

What it is: An older protocol that downloads emails to a single device and typically deletes them from the server.

How it works: The email client connects, downloads all new messages, and disconnects. The server is left empty. This protocol is rarely recommended for modern businesses; it creates data silos (if your device crashes, your email history is gone), and because all emails are downloaded to your device, it can create storage issues on your computer.

Security note: Lack of server-side redundancy makes it vulnerable to hardware failure and theft. This high-risk protocol is not recommended, especially for businesses.

Read more: What are SMTP, IMAP, and POP3?

SMTP and IMAP serve opposite purposes, but a functional email setup requires both protocols. SMTP sends messages out, while IMAP retrieves incoming messages. Most modern email providers hide this complexity, and the software automatically configures both the SMTP and IMAP settings in the background. You rarely have to think about which one you’re using—the software simply handles both simultaneously.

Email security protocols

Email protocols move and store messages, but email security protocols are the systems that keep emails, senders, and recipients safe. They fall into two categories: those that encrypt data to keep it private, and those that authenticate senders to prove identity.

Encryption protocols

Transport Layer Security (TLS): Encrypts the connection between mail servers as emails travel across the internet. Most modern email providers enforce TLS by default.

STARTTLS: A command that upgrades an existing unencrypted connection to a secure TLS connection. If the other side doesn’t support it, the connection falls back to plain text, which is a potential vulnerability.

Secure/Multipurpose Internet Mail Extensions (S/MIME): Provides end-to-end encryption and digital signatures at the message level. It requires both sender and recipient to exchange digital certificates, which makes it more common in enterprise environments.

Pretty Good Privacy (PGP) / GNU Privacy Guard (GPG): Another method of end-to-end encryption and digital signing that offers strong privacy. Instead of certificates, PGP uses a web-of-trust model where users exchange public keys directly.

Authentication protocols

Sender Policy Framework (SPF): Lets a domain owner publish a list of authorized IP addresses that are permitted to send emails on behalf of that domain. When a receiving server gets a message, it checks the sender’s IP against this list. If the IP isn’t on it, the email fails SPF.

DomainKeys Identified Mail (DKIM): Adds a cryptographic signature to each outgoing email, tied to the sending domain. The receiving server verifies this signature against a public key published in the sender’s DNS records.

Domain-based Message Authentication, Reporting, and Conformance (DMARC): Ties SPF and DKIM together and gives domain owners control over what happens when authentication fails. Through a DMARC policy, you can instruct receiving servers to accept, quarantine, or reject failed messages, and you receive reports showing who is attempting to send unauthorized emails from your domain.

Why this matters for SMBs

Without security protocols layered on top of your core protocols, you’re at risk of:

Spoofing: Attackers can easily impersonate your domain to scam your customers
Interception: Unencrypted traffic allows hackers to read emails in transit
Blacklisting: Poor authentication leads to your domain being flagged as spam

Together, these email security protocols create a layered defense—encryption keeps prying eyes off the content, and authentication ensures the email actually came from who it claims to be from.

How protocols impact email marketing success

For SMBs, email marketing introduces a wrinkle: you may not be the one sending the emails. Whether you use a marketing tool or run campaigns yourself determines what you’re responsible for securing.

If you’re using a marketing tool

Platforms like Mailchimp, HubSpot, and SendGrid handle the sending infrastructure, including SMTP servers and encryption. But they can’t authenticate your domain on your behalf. That part is yours.

When a marketing tool sends an email using your domain, for example, newsletter@yourcompany.com, the recipient’s server still checks your domain’s authentication records:

SPF: Must include the marketing tool’s sending IPs so the recipient’s server knows they’re authorized to send on your behalf.
DKIM: The marketing tool signs the email with a cryptographic key, but you must publish the corresponding public key in your DNS records so the recipient can verify it.
DMARC: Tells receiving servers what to do if SPF or DKIM fails, and sends you reports so you can monitor for unauthorized use of your domain.

Most reputable marketing tools walk you through this DNS setup during onboarding. If yours doesn’t, that’s a red flag.

If you’re running your own campaign

Sending bulk emails from your own SMTP server puts the full responsibility on you. You need to:

Configure your SMTP server to use TLS/STARTTLS for encrypted transmission
Set up SPF, DKIM, and DMARC records for your domain
Monitor your sender reputation—shared or poorly managed SMTP servers are a common route to blocklisting
Start with a low sending volume and increase it slowly over time to build trust with inbox providers

This approach gives you more control but requires significantly more technical expertise and ongoing maintenance. For most SMBs, a reputable marketing tool is the safer and simpler path.

Data ownership and business continuity

For an SMB, email isn’t just communication; it’s a record of transactions, agreements, and client relationships.

The POP3 trap: If your team uses POP3 and an employee’s laptop crashes, you may lose years of correspondence permanently because the data was never saved on the server.

The IMAP advantage: By keeping emails on the server, you ensure that data survives hardware failures and employee turnover. It also allows administrators to archive and search communications for compliance audits.

Even if POP3 feels cheaper or simpler, the risk of losing critical business data makes IMAP the safest option for a growing company.

An email protocol security checklist for SMBs

Ready to secure your email infrastructure? Follow this step-by-step guide:

Audit your current setup:
- Are you using TLS/STARTTLS for all connections? (Check your provider settings).
- Are you still using POP3? If so, plan a migration to IMAP immediately.
Implement authentication records:
- Log in to your DNS provider.
- Add your SPF record (include all authorized sending IPs).
- Generate and publish your DKIM key.
- Set up a DMARC policy (start with monitoring).
Secure your marketing stack:
- Ensure your email marketing platform is configured to send via your custom email domain, not a generic subdomain.
- Verify that your domain passes all three authentication checks before sending bulk campaigns.
Test and monitor:
- Send test emails to Gmail, Outlook, and Yahoo.
- View the email headers to confirm authentication passed.
- Subscribe to DMARC aggregate reports to monitor for unauthorized usage.

Don’t wait for a breach or a blacklisting event to audit your email infrastructure. Start with the checklist above, and build a system that supports your business growth securely.

Need help implementing end-to-end encryption or securing your business email? Explore Proton’s business solutions for enterprise-grade privacy and security.

How to attach an email to an email

Greg Ng — Fri, 31 Jul 2026 16:09:32 GMT

When you forward an email, formatting can get messy, and metadata, such as timestamps and subject lines, are sometimes stripped out. If you’re forwarding a business email as a verifiable record or want the recipient to see exactly what you received, attaching the email keeps the original message fully intact.

Most email services attach emails as .eml files, which preserve original formatting and attachments. You can attach an email to an email in Gmail, Outlook, and Proton Mail.

How to attach an email to an email in Gmail

Forward an email as an attachment

Select the checkbox next to the emails you want to forward as an attachment.
Select More (or the three vertical dots) and select Forward as attachment.
Add your recipients, compose your message, and click Send.

You can forward as many emails as attachments as you want, but if the total exceeds 25 MB, Gmail will attach them via a Google Drive link.

Find out more about Gmail’s attachment size limits and how to send large files via email.

Download and attach an email

Open the email you want to send as an attachment.
Click the three vertical dots in the email and select:

Download message: To save the email as an .eml file.
Print: To save the email as a .pdf file.

In your new email, select Attach files (the paperclip icon) to attach the downloaded email. You can also drag and drop a previously downloaded email directly into the message body.
Add your recipients, compose your message, and click Send.

Note: To ensure the email appears as the original when saving as .pdf, check that Headers and footers and Background graphics are selected. You can do this by selecting More settings from the pop-up.

How to attach an email to an email in Outlook

There are two versions of Outlook: New Outlook and Classic Outlook. The steps are broadly similar, with differences marked below.

Forward an email as an attachment

Open the email you want to forward as an attachment.
Select More actions (the three horizontal dots) → Other reply actions → Forward as attachment.
A new email window opens with the email attached as an .eml or .msg file, depending on your Outlook version.
Add your recipients, compose your message, and click Send.

Download and attach an email

Open the email you want to send as an attachment.
Select More (the three horizontal dots) and select:
- Download: To save the email as an .eml (or .msg if using classic Outlook).
- Print: To save the email as a .pdf file.
In your new email, select Attach a file to this item (the paperclip icon) to attach the downloaded email. You can also drag and drop a previously downloaded email directly into the message body.
Add your recipients, compose your message, and click Send.

How to attach an email to an email in Proton Mail

To attach an email in Proton Mail, you must download and upload the email to your draft.

Download and attach an email

Open the email you want to send as an attachment.
Select More (the three horizontal dots) and select:
- Export: To save the email as an .eml file.
- Print: To save the email as a .pdf file.
In your new email, select Attachments (the paperclip icon) to attach the downloaded email. You can also drag and drop a previously downloaded email directly into the message body.
Add your recipients, compose your message, and click Send.

Proton’s privacy-first design means all your emails are end-to-end encrypted by default, so that they remain secure and private. When you export an email from Proton Mail, the exported file is decrypted locally on your device so it can be viewed in other email clients or applications.

Attaching emails works better than forwarding

Attaching an email instead of forwarding it helps preserve the original message, including formatting, timestamps, attachments, and sender details. Whether you use Gmail, Outlook, or Proton Mail, attaching emails can make conversations clearer and provide a more reliable record of what was originally sent.

If you regularly share sensitive business emails or documents, using a privacy-first email service like Proton Mail helps keep your communications secure with end-to-end encryption by default.

Fix your internal documentation before it becomes a liability

Alanna Alexander — Fri, 31 Jul 2026 16:02:58 GMT

Done properly, internal documentation is how a business stays consistent and coherent as it grows. Done badly, it becomes a liability.

When internal documentation is an afterthought, two problems result.

The first is disorganization, which results in wrong versions, buried policies, onboarding materials nobody has updated since the company was half its current size. The second is data exposure: sensitive data sitting in places it shouldn’t be.

Most teams are managing the first issue (even if they feel overwhelmed by it). The second issue is harder to solve, but considerably more dangerous when it isn’t.

Sensitive internal data is a common breach vector across industries. Proton research shows that 39% of businesses report experiencing a cybersecurity incident caused by human error. Often, it’s just well-meaning colleagues making mistakes with sensitive files.

Here’s a practical framework for internal knowledge management that keeps sensitive data secure without making it harder for your team to do their jobs.

The organization problem

When internal documents are disorganized, you’ll soon know about it. Mostly due to the frustration and confusion it causes across your business.

For example, let’s say there are three versions of the employee handbook in your drive, plus onboarding materials that haven’t been updated since the company had 10 people on the payroll. This makes onboarding slow and inconsistent, and gives new starters the wrong impression about how your business functions.

Or let’s say that several important company policies aren’t in a clearly marked folder, but buried somewhere in an email thread. Managers are left making best guesses about policies and can’t enforce them consistently. One employee gets one answer, another gets a different answer.

Disorganization is fixable with the right system (we’ll get to that shortly). But there’s a second problem that you can’t solve with a better folder structure.

The security problem

However well organized your document storage is, if the processes and tools that deal with those documents are lacking, sensitive information will be exposed.

It might be salary bands stored in a shared Google Sheet, source code or API keys pasted into a Slack channel, a client contract emailed as an attachment, or candidate interview notes containing personally identifiable information, carelessly forwarded and now sitting in six inboxes.

When easily overlooked practices like these cause a data breach, you’re no longer contending with frustrated colleagues and obstructed processes. Instead, you’re looking at reputational damage and severe financial penalties.

Much of this data, whether it’s employee records, customer information, or financial details, is personal or sensitive data under GDPR. That means whoever handles it is responsible for how it’s stored, accessed, and shared. And accidents don’t remove culpability.

In 2022, a UNIQLO HR staff member responded to a payroll request by accidentally emailing a PDF containing the salary data of 446 employees. The Spanish data protection authority fined UNIQLO €270,000. The breach wasn’t caused by hackers. It was caused by the absence of organizational measures around a routine HR process.

How to build an inernal documentation system that solves both problems

Think of what you’re building as a secure company wiki. You’re going to need four categories of internal documentation, each with different sensitivity levels and access requirements.

Category 1: Reference knowledge

This is the material every employee should be able to find on their own: company policies, brand guidelines, how-to guides, tool documentation, org charts. Securing this category isn’t about restricting access — it’s about accuracy. Focus on version control (one current version, not five conflicting copies floating around) and clear ownership (one named person responsible for keeping each document up to date).

Category 2: Team and project knowledge

This is where most day-to-day work actually lives: project plans, process documentation, meeting notes, roadmaps, internal playbooks. It doesn’t need company-wide access, so protect it with team-level or project-level permissions instead. Like reference knowledge, each document needs a named owner and a review cadence, or it quietly goes stale.

Category 3: Confidential and regulated data

This is the highest-risk category, and it exists in every department: financial reports and forecasts, legal contracts, employee and customer records, strategic plans, security credentials. These need tightly restricted access, limited to the specific individuals or team who need them. (A password isn’t enough here. You need end-to-end encryption.)

This kind of data also shouldn’t be attached to emails, saved to personal drives, or shared via links with no expiration date.

Proton Drive is a business cloud storage that handles this category with zero-knowledge encryption — not even Proton can read the contents — plus granular access controls that keep sensitive data where it’s supposed to stay.

Category 4: Externally shared materials

Some documents need to leave your internal system temporarily: onboarding packs for new hires, files shared with contractors or vendors, materials sent to clients during a project. This is tricky precisely because access often has to be granted before a relationship is fully vetted. The fix is straightforward: set links to expire, pre-stage access rather than granting it ad hoc, and revoke it the moment it’s no longer needed.

Proton Drive sets expiration dates for links by default, so shared materials expire automatically without anyone needing to remember to revoke them.

Choosing the right platform for secure internal knowledge management

The framework we’ve outlined can be used on any platform. But not just any platform can ensure that the framework enforces itself instead of relying on people remembering to follow it.

Human error inevitably creeps in when you rely on manual processes to set expiration dates on shared links, review access at offboarding, and maintain permission tiers as the team grows. But with the right platform, your framework can be enforced through automation.

There’s a second requirement for your platform: a privacy-first design. Many consumer-grade platforms aren’t designed to store sensitive information: in fact, by default they harvest document content to feed into their search indexing and AI features.

Most companies wouldn’t dream of storing customer data in an unsecured Google Drive folder. Employee data deserves the same standard. The right platform will handle both enforcement and end-to-end encryption.

Three decisions that will keep your system running

A good cloud platform will enforce your security framework, but even the best platforms can’t check and update your documents for you.

Unmaintained documentation creates two types of risk.

There’s legal risk: an outdated disciplinary procedure can invalidate a tribunal case, for example.

There’s cultural risk: when official documentation doesn’t reflect reality, employees notice, and conclude nobody is in control.

Follow these three rules and you can avoid both:

Every document has a named owner (not a team). Responsibility shared across a team is a responsibility nobody feels
Review dates are set at creation, not added later. It’s difficult to defend a document at a tribunal when it hasn’t been reviewed in three years (or there’s no record of when it was last checked)
Archive documents, don’t delete them. Deleting documents spells trouble if you (or a regulator) ever need to access them. Archiving them in a clearly labeled folder keeps your system clean without making documents irretrievable

None of this requires a dedicated knowledge manager. Just three decisions, made once (and revisited quarterly).

A compliance checklist for internal HR documentation

Remember: you are the data controller. The responsibility doesn’t sit with your cloud provider, it sits with you.

Do you know who has access to your most sensitive documents — financial, legal, employee, or customer data — and is that list current?
Are sensitive documents encrypted at rest, not just in transit?
Do shared links on sensitive documents have expiration dates?
Is there a documented process for revoking access when someone leaves or a project ends?
Can you produce an audit trail of who accessed what and when?
Is sensitive data stored in a jurisdiction with strong privacy laws, like Switzerland?
Does every document have a named owner and a review date?
Are superseded documents archived rather than deleted?

If you can answer yes to all of these, your documentation system is in good shape.

A secure knowledge base your employees can trust, and a platform to deliver it

The framework in this guide gives you the structure. You need a platform that enforces it, so the security standards you’ve set don’t depend on humans remembering to apply them.

Look no further than Proton Workspace. A secure collaboration suite, built on end-to-end encryption and hosted in Switzerland, one of the world’s strongest privacy jurisdictions, Proton Workspace gives your team:

Real-time collaborative editing
Encrypted business cloud storage
Secure professional email
Secure video conferencing
Admin controls designed to scale with your business

Your employees trust you with their most sensitive data. It’s time to build an internal documentation system that’s worthy of that trust.

Start free trial of Proton Workspace

Are AI detectors accurate?

Alanna Alexander — Fri, 31 Jul 2026 15:55:21 GMT

AI presents businesses with real opportunities to improve efficiency. It also brings new challenges, which is why businesses are increasingly looking to use a specific form of AI against AI: AI detectors.

There are legitimate reasons to use AI detectors: protecting brand voice, fraud detection, spotting plagiarism, getting value for money from contractors, and more.

But AI detectors aren’t infallible, and for most businesses the risks of using them outweigh the benefits. Here’s what you need to know before you use one.

How do AI detectors work?

AI detectors are specialized software that mathematically analyze patterns to estimate the probability that text was machine-generated. Popular detectors include GPTZero, Copyleaks, Originality.ai, Sapling, Turnitin, and Grammarly AI Detector.

What AI detectors look for, in technical terms, comes down to two metrics:

Perplexity measures how predictable a sequence of words is. Lower predictability means less likelihood of AI involvement, because AI models are trained to guess and use the most statistically probable words. Humans make more varied and eccentric word choices.
Burstiness measures variation in sentence length and complexity. Human writing “bursts” with a mixture of sentence-types, whereas probability-seeking AI tends to write in a regular, smooth, almost mathematical way. Low burstiness writing strongly indicates AI-involvement to a detector.

Some AI detectors also use stylometric analysis, evaluating vocabulary choice and grammar, hunting down suspiciously rigid and formal structures.

A handful of AI models are starting to use watermarking, which involves embedding invisible and detectable patterns into AI-generated text at the point of creation. But because most models don’t currently leave a trail, you can’t yet rely on this solution.

Are AI detectors reliable?

AI detectors are never 100% reliable, and they’re often significantly less reliable than that.

Accuracy varies significantly between tools, content type, and (critically) exactly how AI was used to create the analyzed content, if it was used at all.

When detectors work

Paste unchanged (or ‘raw’) AI output into any AI detector and the detector will detect it. Raw output is easy for the detector to identify because the statistically probable pattern it’s looking for hasn’t been broken.

For example, we pasted text generated directly from Claude Sonnet 4.6 into Sapling. Sapling had 99.5% confidence that this AI-generated text was AI-generated.

Sapling correctly flags the raw AI-generated paragraph.

Originality (another leading AI detector) flagged the same paragraph as AI with even greater confidence: 100%.

Originality is even surer that our raw AI text is AI-generated.

Detectors can also identify AI-writing when the text submitted isn’t 100% AI generated, although significantly less reliably, especially when the text is short (less than 300 words) and the patterns detectors are looking for don’t have time to establish themselves.

When detectors fail

It’s well-documented that AI detectors find false positives: signals of AI use in text entirely written by humans. One recent peer-reviewed study of academic writing rated the overall accuracy of Originality and Turnitin when identifying AI-generated academic texts as only 69% and 61% respectively.

One issue is that humans often naturally write like AI, particularly if they’re non-native language speakers, who (like LLMs) use simple, highly grammatical phrasing. A Stanford study had seven popular AI detectors analyze Test of English as a Foreign Language essays by Chinese students. The average false positive rate was 61.22%.

It’s also hard for detectors to spot when humans deliberately disrupt the statistical patterns they’re looking for. AI-assisted authors don’t have to do much to break those patterns: rewrite a few sentences, vary sentence structure, use less predictable words.

If this seems like too much work, they can get it done for them by one of the increasing array of ‘humanizer’ tools that have inevitably arisen to outsmart detectors.

They can also simply stick to their chosen LLM and use smarter prompts. A 2025 study of 12 AI detectors found that “minimal polishing with GPT-4o can lead to detection rates ranging from 10% to 75%, depending on the detector”.

We asked Claude Sonnet 4.6 to write a 300 word essay about AI detector accuracy, and asked it to write like a human, with varied sentence lengths, direct opinion, and unexpected word choices. Sapling scored the text as only 12% likely to be generated by AI.

Sapling fails to identify cleverly-prompted Claude text.

Originality analyzed the same text and declared that it was 100% confident that the text was AI generated.

Originality scores the same text 100% AI: the opposite verdict, with equal confidence.

Originality looks to be the superior tool based on this test, but it’s important to recognize that both tools were equally confident in their analysis. If you wrote the analyzed text, you’ll know which detector is correct. If you didn’t, then you can never be sure.

How AI detectors endanger your data

The bigger issue with AI detectors is one that many businesses overlook entirely: the risks they present to the privacy and security of your data. These are similar risks to those posed by AI in general:

Compliance risks: Detection models inherit biases from training data, creating potential for discriminatory outcomes and breaking equal opportunity laws. Many detectors are “black boxes”, and frameworks like the EU AI Act and the NIST AI Risk Management Framework demand organizations must provide meaningful logic for AI outputs.
IP and training data risks: Many AI detectors have Terms of Service (ToS) that grant the provider the right to store, analyze, and use submitted data to train future models.This can mean that your provider has the legal right to use whatever product roadmaps, financial projections, and proprietary research you’ve submitted with no obligation to guarantee its privacy or prevent it surfacing in a competitor’s output.
Data security risks: AI detectors are vulnerable to cyberattacks, and submitting content to a third-party detector extends your attack surface to include your provider’s. If your provider suffers a breach, your data will be in it. Free, unvetted tools — the very type employees can be tempted to reach for — won’t let you audit a provider’s security practices in advance.
Data sovereignty risks: Submitting a document to a detector can mean transferring text to foreign servers, potentially stripping it of local protections and exposing it to extraterritorial government surveillance under the CLOUD act.

For most businesses, the question isn’t whether AI detectors work: it’s whether the risks of using them are worth taking. If you’re working with any sensitive, original, or confidential data, the answer is no.

FAQ on AI detectors

How do AI detectors work?

AI detectors scan text looking for patterns they’ve been trained to associate with AI-generated text. These patterns appear because AI generates text by algorithmically predicting and using the most probable next word.

What do AI detectors look for?

The main indicators of AI-generated text that detectors look for are low levels of ‘perplexity’ (unpredictable word choices) and ‘burstiness’ (variation in sentence length and structure).

Some AI models are starting to experiment with watermarking, which means embedding invisible (but detectable) patterns into text at the point of generation. However, since only a few models have started to do this, watermarking doesn’t yet provide a foolproof test for AI-generated text.

Do AI detectors work?

Accuracy depends on the detector used, the type of text being analyzed, and how (if at all) AI has been used to generate the text. Detectors perform well on raw, unedited AI output. On anything more complex — edited content, human writing by non-native speakers, AI output that’s been lightly paraphrased — accuracy drops significantly.

Accuracy aside, the bigger problem with AI detectors is the threat that using them can pose to your data security. Submitting content to a third-party detector means transferring it to external servers, potentially exposing it to cyberattacks, data harvesting, extraterritorial surveillance, and handing a provider legal rights to your submitted content.

For most businesses, especially those working with any sensitive, original, or confidential content, the data risks that come with third-party AI detection outweigh the benefits.

We’ve improved autofill for Proton Pass

Son Nguyen Kim — Thu, 30 Jul 2026 15:50:49 GMT

The latest version of Proton Pass includes a few updates our community has been anticipating.

Improving autofill has been one of the main community requests for Proton Pass. We heard you, and we’ve worked hard to deliver a significant improvement: The new version resolves 80% of the autofill issues users reported to us.

We’ve also improved the 2FA autofill. On the business side, we made it easier to roll out Proton Pass across an organization.

We’ll explain below how each update works and what to expect.

Easier, faster logins with improved autofill

Proton Pass now autofills on sites where it previously couldn’t, including shopping platforms, social media sites, forums, and banking websites.

This improvement comes from an upgrade to how Proton Pass detects forms on the website you’re visiting. Some websites don’t put login forms directly on the page, instead loading them inside a separate frame known as an iframe. Autofill can now accurately detect those frames, so Proton Pass can autofill more of the forms you encounter.

We’re continuing to improve autofill over the coming months, including URL matching, support for native autofill on Mac, and adding more supported languages.

A more robust 2FA autofill

Two-factor authentication (2FA) is one of the best ways to protect your online accounts, which is why you can create and store 2FA codes within Proton Pass.

When you’re logging into an account, you’ll usually see a prompt to autofill your 2FA code. However, in some cases the prompt doesn’t appear, forcing you to switch apps to manually copy and paste the code.

You can now choose to automatically copy your 2FA codes to your clipboard, so even if the 2FA autofill isn’t prompted, the code is ready to paste.

With this improvement, you won’t have to switch apps to find the code you need. 2FA won’t slow you down anymore, and signing in stays easy and secure.

Roll out Proton Pass with ease

The Proton Pass Windows installer has now moved from .exe to .msix, which works natively with Microsoft Intune. .msix gives users a cleaner, safer install — it’s sandboxed, easy to fully uninstall, and offers automatic delta updates.

This means admins can deploy and maintain Proton Pass across all company devices centrally, instead of machine by machine. It’s also an easier experience for individual users, offering a more predictable and contained installation than .exe.

If you’re an IT admin, making changes to your IT infrastructure can often take significant time and effort. With this change, deploying and managing a new password manager is now quicker, lower-effort, and more reliable, not a manual task you need to repeat on every machine.

More improvements in this release

Check for updates in the desktop app: A new button in Settings on macOS and Windows makes it easy to check whether you’re on the latest version.
Liquid glass animations: The iOS app now uses Apple’s latest design language, with a more refined and modern visual experience
Username generator: You can now generate usernames on iOS, alongside passwords and email aliases.

Your feedback is important

Your feedback has helped us make these changes, and we want to know what else you need from Proton Pass. Let us know what you’d like to see on Reddit, UserVoice, and X.

Thank you for being part of our community and supporting us as we build this privacy-first password manager.

Data classification for businesses: how to organize and protect company information

Ben Wolford — Tue, 28 Jul 2026 13:44:10 GMT

Data classification helps businesses stop treating every piece of information as if it carries the same risk. A supplier email, an internal process note, a customer payment record, and an admin recovery code should not move through the business under the same rules.

Sensitive data is stored throughout your business network: It moves through CRMs, inboxes, cloud storage, spreadsheets, HR systems, support platforms, finance software, and vendor tools. Without a shared system for classifying it, teams often rely on instinct: if something looks safe to share, or probably needs approval, they’ll take the quicker, easier route.

This may work for a while, but it doesn’t scale. A clear data classification policy gives your business a common language for deciding which information can be public, which should stay internal, which needs tighter controls, and which should only be available to specific roles.

What is data classification?

Why data classification matters

A simple data classification framework

Data classification examples for business teams

How classification drives access control

Sharing classified data safely

Start with a data audit

How to create a data classification policy

How Proton Pass for Business supports data classification

Make classification part of everyday data protection

What is data classification?

Data classification is the process of labeling business data by how sensitive it is and how much harm it could cause if it is exposed, changed, lost, or misused. In practice, it means grouping information into clear levels so people know how to store it, share it, protect it, and eventually delete it.

A useful classification system fits into daily work. It gives employees a quick way to understand when information can move freely, when it needs approval, and when access should be limited to a small group. The goal is to make the safer decision obvious before data is copied, shared, exported, or stored somewhere it should not be.

The UK National Cyber Security Centre’s guidance on asset management treats information as an asset that needs visibility, ownership, and protection. This is a useful way to frame classification: before deciding who can access sensitive data, you need to know what that data is and where it lives.

Why data classification matters

You can’t protect what your business hasn’t identified. This is especially true for SMBs, which usually do not have the resources to protect every system and every type of information with the same level of control. Before a business can decide who should access sensitive data, which systems need stronger protections, or where MFA and secure sharing are most urgent, it needs to know what information it holds and which data matters most.

Data classification is the first step in a practical data breach protection strategy. It separates routine business information from data that could create real harm if exposed, changed, lost, or shared with the wrong person.

This is especially useful as information spreads across CRMs, inboxes, cloud storage, HR systems, support tools, finance software, exports, and vendor platforms. Classification gives employees a clear signal: what can be handled normally, what needs approval, and what should only be available to specific roles.

It also supports compliance. The UK’s Information Commissioner’s Office (ICO), the authority responsible for data protection enforcement and UK GDPR guidance, expects organizations to apply appropriate technical and organizational measures. Classification helps make that practical by matching protection to the sensitivity of the data.

For breach prevention, the principle is simple: sensitive data should not be accessible to more people than necessary. Proton’s guide to data loss prevention for businesses explains how reducing unnecessary exposure before an incident can limit the damage afterward.

A simple data classification framework

A classification framework doesn’t need to be complicated. Four levels are usually enough for small and midsize businesses:

Public
Internal
Confidential
Restricted

Public

Public data is information approved for external use. A published version of this article you are reading, for example, would be Public data: it can be read, safe to share openly, and indexed without creating meaningful security or privacy risk.

Other examples include:

Website copy
Press releases
Public job descriptions
Approved sales materials
Product pages
Public company descriptions.

Public information still needs accuracy and brand review, but it doesn’t usually need strict access control once it has been approved.

Internal

Internal data is meant for employees and approved collaborators only, but not for public distribution. Exposure may not cause severe damage, but it can create confusion, reputational risk, or operational issues.

Examples include:

Internal process documents
Team notes
Standard operating procedures
Training materials
Non-sensitive project plans
Internal calendars
General vendor contact lists.

Internal data should stay in approved business systems. For example, a draft campaign brief, an onboarding checklist, or notes from a team planning meeting may not be highly sensitive, but they still belong in the company’s approved workspace, not in a personal folder, private inbox, or unmanaged download.

Confidential

Confidential data is sensitive business or personally identifiable information (PII) that could harm the company, customers, employees, or partners if exposed. Access should be restricted to approved roles with a clear business need.

Examples include:

Customer records
Employee files
Contracts
Commercial terms
Financial reports
Sales pipeline details
Support tickets containing personal data
Unpublished business plans
Non-public vendor agreements

Confidential data should only be accessible to approved roles. It shouldn’t live in personal drives, open shared folders, unmanaged spreadsheets, or inboxes where nobody reviews access. If it needs to be shared externally, the business should use end-to-end encrypted (E2EE) business cloud storage and limit sharing to authorized recipients with a clear business purpose.

Restricted

Restricted data is the most sensitive category. If it is exposed, misused, or changed, the business could face serious financial, legal, operational, or security consequences.

Examples include:

Admin credentials
Recovery codes
Authentication secrets
Customer payment details
Highly sensitive HR records
Legal dispute files
Security incident reports
Privileged access logs
Encryption keys
Backup access details

Restricted data needs the strongest controls: limited access, strong authentication and credential management, end-to-end encrypted cloud storage, secure sharing, and auditability.

Classification level	Sensitivity	Examples	Access level	Sharing rules
Public	Low	Published articles, website copy, press releases, public job posts, approved sales materials	Approved for external use	Can be shared publicly once reviewed and approved
Internal	Moderate	Team notes, draft campaign briefs, onboarding checklists, internal process documents	Employees and approved collaborators	Keep inside approved business systems
Confidential	High	Customer records, employee files, contracts, financial reports, support tickets with personal data	Approved roles only	Share only with authorized recipients and a clear business purpose
Restricted	Highest	Admin credentials, recovery codes, payment details, security incident reports, privileged access logs	Named users or tightly controlled groups	Do not share through email, chat, screenshots, or unmanaged documents

Data classification examples for business teams

Classification becomes easier when teams can recognize it in their own work. Finance teams may treat a public pricing page as public, while invoices, payroll files, tax documents, and payment records are usually confidential. Banking credentials and payment platform admin access should be restricted because they can expose information, change settings, or move money.

In practice, that access should be controlled through role-based permissions, strong authentication, regular access reviews, and a business password manager that helps teams manage and control the credentials behind sensitive systems.

HR data follows a similar pattern. A job posting can be public, while employment contracts, salary information, sickness records, benefits details, and candidate data are usually confidential. Sensitive investigations, HR admin credentials, and broad access to employee records should be restricted.

This is not a historical anomaly: the 2022 ICO fine against Interserve, totaling £4.4 million, is a stark warning that employee data should be classified and protected as sensitive business information, not treated like ordinary internal documentation.

Sales, customer success, marketing, and IT teams also need clear boundaries. Customer records and support tickets that contain personal or account-level information are often confidential. Internal segmentation work, campaign planning, and performance reports may be internal or confidential depending on whether they include customer-level data, commercial sensitivity, or non-public business strategy.

Vendor documentation should be classified based on what it contains, especially if it includes access details, commercial terms, or security information. Exported customer datasets, CRM admin access, admin access to advertising platforms such as Google Ads or Meta Business Manager, backup credentials, recovery codes, privileged access logs, and security tooling credentials should be restricted because one exposed file or account can affect far more than one person.

How classification drives access control

Once data is classified, access stops being a generic permission setting and becomes a business decision. The question is no longer only whether someone can open a system, but whether their role justifies access to the information inside it.

A support team may need customer conversations, but not every exported customer file. Finance may need payment and accounting records, but not HR investigations. A contractor may need access to one project workspace, not the company’s full archive of client files.

For confidential and restricted data, access must leave an audit trail. The business should know who accessed what, why access exists, and whether permissions are revoked immediately after a role change or offboarding.

A password manager for IT teams supports centralized management, secure sharing, policies, admin reporting and logs, SCIM provisioning, and SSO integrations. This helps teams scope access to the credentials that unlock sensitive systems, instead of leaving passwords in browsers, spreadsheets, or chat threads.

Sharing rules should follow the sensitivity of the information. A published asset can circulate freely once approved, but a contract, customer file, payment record, or recovery code needs more control. The more sensitive the data, the fewer people should receive it, and the more deliberate the sharing method should be.

This is especially important for email. Many businesses still send sensitive information through attachments, screenshots, or copied text, then lose track of where that information goes. Proton’s guide on how to securely send sensitive information via email explains safer ways to handle sensitive information when email is necessary.

Credentials and secrets need stricter rules than ordinary documents. Passwords, recovery codes, passkeys, and admin access details shouldn’t be sent through email, chat, screenshots, or shared documents. They should be stored and shared through a business password manager such as Proton Pass for Business⁠ where access can be controlled, reviewed, and revoked more safely.

Start with a data audit

Before writing a data classification policy, map where business data already lives. The first audit doesn’t need to be perfect. It just needs to show which systems hold sensitive information, who can access them, and where uncontrolled copies may exist.

Start with everyday locations such as CRMs, HR platforms, finance software, cloud storage, email inboxes, shared drives, support tools, password managers, vendor portals, downloads, exports, and backups.

Field	What to record
Location	Where the data lives
Data type	Customer, employee, financial, credential, or operational data
Classification level	Public, internal, confidential, or restricted
Owner	Person or team responsible
Access	Who can view, edit, export, or share it
MFA	Whether multi-factor authentication is enabled
Vendor sharing	Whether third parties can access it
Retention status	Keep, review, delete, or anonymize

How to create a data classification policy

A data classification policy should be short enough for employees to use and specific enough to guide real decisions. It should define the classification levels, explain who owns sensitive data, and connect each level to access, storage, sharing, retention, and review.

A simple policy can include:

Purpose and scope: What the policy covers and who it applies to.
Classification levels: Public, internal, confidential, and restricted, with examples.
Ownership: Who approves access and handles review for sensitive data categories.
Access rules: Who can access each level and how access is approved or removed.
Sharing rules: Which channels are approved for each classification level.
Storage and retention: Where each type of data should live and how long it should be kept.
Review cadence: How often the policy and access rules are reviewed.
Legal hold process: When deletion or retention rules must be paused during active investigations, disputes, or litigation.

The policy should also make room for judgment. Not every document will fit neatly into a category. When in doubt, employees should know who to ask and what default to follow. For sensitive data, the safer default is usually to restrict access until the right owner confirms otherwise.

How Proton Pass for Business supports data classification

Data classification tells your business which information needs stronger protection. Access control turns that decision into daily practice.

Credentials are part of that access layer. If a password gives access to restricted data, such as admin settings, customer exports, finance systems, recovery codes, or security logs, that credential needs stricter handling than a login for a low-risk internal service.

A secure business password manager like Proton Pass for Business helps teams apply those access decisions in practice. Credentials can be stored in encrypted vaults, organized by team or function, and shared only with the people who need them.

Admins also get better visibility into credential access through reporting and logs, while policies, SSO integrations, and SCIM provisioning help IT teams manage onboarding and offboarding more consistently.

This makes classification easier to enforce in daily work. Finance credentials can stay with finance. HR admin access can stay with authorized HR leads. Backup recovery codes and privileged admin logins can be limited to the people responsible for recovery and security.

Make classification part of everyday data protection

Data classification is not paperwork for its own sake. It is a way to make data breach protection easier to follow in daily work.

Once your business knows which data is most sensitive, the next step is controlling who can reach it. A password manager can help teams control and monitor the credentials that unlock sensitive systems and restricted data.

Control access to classified data across your organization with a business password manager.

IT disaster recovery plan: how to build one for your SMB

Kate Menzies — Tue, 28 Jul 2026 13:10:57 GMT

When a key system within your business goes down, the hardest parts are knowing what to restore first, who has the access to do it, which backup can be trusted, and how long your business can keep working without that system.

That is where many small and midsize businesses (SMBs) discover the gap between having backups and having an actual recovery plan. A backup may contain the data you need, but it doesn’t decide the recovery order, assign responsibilities, validate whether the restore works, or solve the problem of missing admin credentials during an outage.

An IT disaster recovery plan gives this process structure before a disruption happens. It defines which systems matter most, how quickly they need to be restored, how much data loss the business can tolerate, what data loss prevention strategies to implement, who owns each recovery step, and how critical credentials are protected. This clarity can prevent an IT incident from turning into prolonged downtime, lost revenue, or a wider operational crisis.

What is an IT disaster recovery plan?

Business continuity vs. IT disaster recovery

What your IT disaster recovery plan must cover

What your IT disaster recovery plan needs to define

Credential recovery: the overlooked disaster recovery scenario

Disaster recovery plan template

How to test your IT disaster recovery plan

Build recovery around systems, data, and access

What is an IT disaster recovery plan?

An IT disaster recovery plan is a documented process for restoring technology systems after a disruption. It focuses on the IT layer of the business: data, applications, devices, infrastructure, cloud services, admin access, backups, and the people responsible for recovery.

A practical IT recovery plan should answer questions like:

Which systems must come back first?
How much downtime can the business tolerate?
How much data loss is acceptable?
Where are backups stored?
Who can restore systems?
Which admin credentials are needed?
How will the team confirm that restored systems are safe and usable?
How will the business communicate with staff and customers if primary channels are down?

A disaster recovery plan should go beyond dealing with cyberattacks: it needs to cover everyday issues like hardware failure, lost credentials, and accidental deletion. It also needs to cover external service interruptions such as cloud platform or SaaS tool disruptions, misconfigurations, and key employees leaving without transferring critical access.

Recovery is not something to design during an outage. It needs to be planned, owned, communicated, and tested before your business needs to depend on it.

Business continuity vs. IT disaster recovery

Business continuity and IT disaster recovery often get treated as the same thing, but they solve different problems.

Business continuity is about keeping the company operating during a disruption. It covers client communication, temporary workflows, staff responsibilities, supplier coordination, and decisions about which services need to continue even if normal systems are unavailable.

IT disaster recovery focuses on the technology behind that work. It defines how systems, data, applications, backups, and admin access will be restored so the business can return to normal operations safely.

As an example, consider a CRM outage. A business continuity plan may explain how sales or support teams keep serving customers while the CRM is down. The IT recovery plan explains who contacts the vendor, which data needs to be restored, which backup or export is available, which credentials are required, and how the team confirms the system is safe to use again.

For many SMBs, the gap appears only during an incident. People know who would contact clients, but not who can restore the billing system. They know backups exist, but not whether a restore has ever been tested. They know one employee usually handles IT, but not what happens if that person is unavailable or where the admin passwords are stored if that person is out of contact.

What your IT disaster recovery plan must cover

A strong IT disaster recovery plan doesn’t have to be overly long, but it needs to be specific enough to run during a stressful situation.

Recovery time objective

Recovery time objective, or RTO, defines how quickly a system needs to be restored. A payment system may need to be back within hours, while an internal reporting dashboard may tolerate a longer outage.

Set RTOs by business impact, not by technical preference, because the cost of downtime is both a business and a technical problem. Ask which systems affect revenue, customer commitments, legal obligations, security, and employee productivity.

Recovery point objective

Recovery point objective, or RPO, defines how much data loss is acceptable, which then helps set the right data loss prevention (DLP) strategies. If a system has an RPO of one hour, backups or replication need to support recovery to roughly that point.

If the RPO is one day, the business is accepting a larger gap. RPO also helps determine backup frequency, because the shorter your RPO, the more frequent your backups need to be. Critical systems therefore need more frequent backups than low-priority systems.

System priority tiers

Not every system should be restored at the same time. A small business disaster recovery plan should divide systems into priority tiers.

Tier 1: Systems required for core operations, security, communication, or revenue.
Tier 2: Important systems that can tolerate short downtime.
Tier 3: Lower-priority systems that can be restored after the business is stable.

Typical tier 1 systems may include email, identity provider, password manager, finance systems, customer database, cloud storage, and communication platforms.

Backup strategy

Your backup strategy should define:

What is backed up and how often
Where backups are stored
Who can access them
How restoration is tested

The NCSC has also published ransomware-resistant backup principles for cloud and on-premises backup solutions, noting that backed-up data is not resistant to ransomware by default and should be assessed against the ransomware threat.

A strong backup strategy usually includes offline or immutable backups for critical data, regular testing, documented restore steps, and separate credentials for backup administration.

Roles and responsibilities

A disaster recovery plan should name owners, not just tasks. If one person holds all recovery knowledge, the business has a people risk as well as an IT risk. Define who:

Leads recovery
Restores systems
Contacts vendors
Approves emergency access
Communicates internally
Documents decisions

What your IT disaster recovery plan needs to define

Component	What it answers
RTO	How quickly does each system need to be restored?
RPO	How much data can the business afford to lose?
Priority tiers	Which systems come back first, and which can wait?
Backup strategy	What is backed up, where is it stored, and has restoration been tested?
Roles and responsibilities	Who leads recovery, restores systems, contacts vendors, and approves emergency changes?

Credential recovery: the overlooked disaster recovery scenario

Disaster recovery often focuses on data, servers, and backups. But in practice, recovery can fail because the team cannot access the systems needed to restore operations.

Credential recovery asks:

Who has access to admin accounts?
Where are backup credentials stored?
Which accounts can restore critical systems?
What happens if a password is lost, compromised, or held by someone unavailable?
Are emergency credentials protected and reviewed?
Can access be revoked and reassigned quickly?

If backup credentials are stored in one employee’s browser, recovery codes are kept in a private note, or shared admin passwords circulate through chat, the business may not be able to recover cleanly during an incident.

A business password manager helps reduce that risk by centralizing critical credentials in encrypted vaults, assigning access by role, and making it easier to revoke or reassign access when someone leaves or responsibilities change. Proton Pass for Business helps teams generate strong passwords, store credentials securely, use secure sharing, and keep sensitive access out of chats and spreadsheets.

As a password manager for IT teams, Proton Pass supports centralized credential management, password policies, secure sharing, reporting and logs, SCIM provisioning, and SSO integrations. That makes credential recovery more manageable because access to critical systems is not dependent on one person, one browser profile, or one undocumented password.

Disaster recovery plan template

A disaster recovery plan works best when it is specific enough to guide action during an outage, but simple enough for the team to use under pressure. For SMBs, the template should focus on the essentials: what needs to be restored, how quickly, from which backup, by whom, and with which credentials.

1. Scope

Define which systems, services, locations, devices, and data the plan covers.

Template copy: This IT disaster recovery plan covers the systems, data, services, credentials, and vendors required to restore [Company Name]’s critical operations after a technology disruption.

2. Critical systems inventory

List the systems your business relies on and assign priority tiers.

Template copy: Critical systems will be grouped into Tier 1, Tier 2, and Tier 3 based on business impact, recovery time objective, recovery point objective, and dependency on other systems.

3. Recovery objectives

Define RTO and RPO for each priority system.

Template copy: Each system must have a documented recovery time objective and recovery point objective. These targets should be reviewed at least annually and after major system changes.

4. Backup and restore process

Document where backups are stored, how often they run, who can access them, and how restore testing works.

Template copy: Backups must be protected from unauthorized access, stored separately from primary systems where appropriate, and tested on a regular schedule. Restore procedures must be documented for Tier 1 systems.

5. Credential and access recovery

Define where critical credentials are stored and who can access them during recovery.

Template copy: Admin credentials, backup credentials, recovery codes, and vendor access required for disaster recovery must be stored in an approved encrypted vault. Access must be limited to authorized roles and reviewed after role changes, offboarding, and recovery exercises.

6. Roles and escalation

Define recovery owners, alternates, and escalation paths.

Template copy: Each recovery role must have a primary owner and a backup owner. The plan must identify who leads recovery, who restores systems, who contacts vendors, who communicates updates, and who approves emergency changes.

7. Communication plan

Define how the business communicates internally and externally during an IT outage.

Template copy: During a recovery event, internal updates will be shared through [approved channel]. External communications to customers, vendors, insurers, or regulators must be approved by [role/team].

8. Testing and review cadence

Define how often the plan is tested and updated.

Template copy: This disaster recovery plan will be tested at least [annually/twice a year] and reviewed after major incidents, system changes, vendor changes, or failed recovery exercises.

How to test your IT disaster recovery plan

A disaster recovery plan only becomes useful when it has been tested under conditions that resemble real disruption. A backup that exists but has never been restored is still an assumption. A recovery role that only one person understands is still a dependency. An admin credential that no one can find during an outage is still a blocker.

Testing does not need to be complex at first. For most SMBs, the goal is to prove that the business can restore the right systems, with the right people, using the right credentials, within a realistic timeframe.

1. Tabletop exercise

Choose a likely scenario, such as ransomware affecting shared files, a cloud storage outage, accidental deletion of customer data, or the sudden loss of access to an admin account. Walk through what the team would do in the first hour, who would lead, which vendors would be contacted, which systems would be prioritized, and what information would be missing.

2. Test restoration

Select a critical file, database, mailbox, or system export and confirm that it can be restored to a usable state. Check whether the restored data is recent enough, whether permissions still work, and whether the team knows where the backup lives.

3. Test regularly

As a practical baseline, SMBs should test the plan at least once a year, in line with NIST guidance in Special Publication 800-34 Revision 1⁠, and more often after major system or vendor changes.

4. Test credential recovery

Confirm that authorized people can access backup admin accounts, cloud admin accounts, vendor portals, recovery codes, and emergency credentials without relying on one employee’s browser, private notes, or memory. The goal is not to expose sensitive passwords unnecessarily. It is to confirm that the access model still works when the business is under pressure.

After every test, document what failed, what took too long, and assign a specific person and deadline for each fix. A good test is not one where everything goes perfectly. It is one that reveals the gaps while the business still has time to fix them.

Build recovery around systems, data, and access

A useful IT disaster recovery plan gives the business a recovery order, a set of owners, a realistic view of acceptable downtime, and a way to maintain business continuity and regain access to the systems that keep work moving.

For SMBs, this might make the difference between a short disruption and a prolonged outage. If email, finance software, cloud storage, customer systems, or admin accounts are unavailable, the team needs to know what comes first, who can act, and which credentials are required to restore access safely.

This is why recovery planning should cover systems, data, and access together. Backups may restore files, but credentials are what let the team regain control of the systems needed to recover. Admin logins, vendor portals, backup accounts, recovery codes, and shared operational credentials all need to be protected, organized, and available to the right people when something goes wrong.

A business password manager helps strengthen that part of the plan. With critical credentials stored in encrypted password vaults and shared only with authorized people, the business is less dependent on one employee’s browser, private notes, or memory during a recovery event.