---
title: Plainrouter Security Policy
description: Plainrouter's Security Policy covers data hosting, credential protection, access controls, governed actions, backups, subprocessors, and incident response.
canonical: https://plainrouter.com/security
last_updated: 2026-11-01
---

# Plainrouter Security Policy

Plainrouter protects first-party signals and advertising-account credentials with layered safeguards. Ask waits for your approval. In Custom, your switches decide which agent changes run on their own. Full runs agent changes that pass admission and workspace policy automatically. Rule violations are blocked and shown in the Inbox. The kill switch stops further writes and never undoes a landed change.
## Security at a glance

- Data region: **European Union**
- Baseline: **ENISA-informed**
- Action authority: **Ask approval, Custom switches or Full within policy**
- Last reviewed: **November 2026**
- Live service status: [status.plainrouter.com](https://status.plainrouter.com)

## How we protect the service

Our controls are intentionally practical: isolate sensitive systems, minimize access, protect credentials and event data, govern provider writes, and keep managed backups.

### Hosting and infrastructure

EU-first infrastructure with production isolated from development.

- Application services, databases, and primary backups are hosted in EU data-center regions.
- Production access is restricted; development and test environments do not use production customer data.
- Network controls, managed edge protection, and continuous health monitoring reduce direct exposure.

### Encryption

Sensitive data is protected in transit and at rest.

- Connections to the service use modern TLS; unencrypted production traffic is not accepted.
- OAuth credentials are encrypted at the application layer using AES-256 before database storage.
- Passwords are one-way hashed. Management keys and Workspace keys are shown once and stored in a non-reversible form.

### Access controls

Least privilege applies to customers, services, and our own team.

- Workspace membership scopes access through owner, administrator, editor, and viewer roles; only owners can delete a workspace. Owners and administrators can manage an existing ad-platform connection. Editors can connect when no healthy connection exists. Viewers are read-only.
- Workspace keys have Read or Write tiers. Management keys use one fixed management ability. Authentication endpoints are rate-limited.
- Users can turn on optional two-factor authentication for web sign-in, including Google and GitHub, with an authenticator app and recovery codes. Accounts without a password set one first.
- Security-relevant account events, including sign-ins, failed password and two-factor sign-in attempts, two-factor changes, member and role changes, Workspace key and Management key creation and revocation, and agent-access grant creation and revocation, are recorded in an append-only log kept for 13 months.
- Privileged internal access is limited to people who need it.

### Backups and recovery

Recovery relies on managed backups and defined targets.

- Core database backups are automatic, encrypted, and retained separately from the live environment.
- The managed core database keeps continuous write-ahead logs for point-in-time recovery plus snapshots at least daily.
- Working recovery targets are a 24-hour recovery point and an 8-hour recovery time for the core service.

### Secure engineering

Security checks sit inside the development lifecycle.

- Every change goes through a pull request with automated tests and code review before release; secrets stay outside source control.
- Dependencies and application behavior are checked for known vulnerabilities and unintended data exposure.
- Platform credentials stay out of serialized responses, and consequential writes stay inside the shared approval pipeline.

### People and operations

Technical controls are supported by clear ownership.

- Security responsibilities have a named owner.
- Risks and controls are reviewed whenever the product or threat landscape changes materially.

## Backups and recovery targets

Backups are encrypted and kept separate from the live environment. We plan recovery around the targets below.

| Target         | Objective                                           |
| -------------- | --------------------------------------------------- |
| Backup cadence | Continuous write-ahead logs; snapshots at least daily |
| Recovery point | 24 hours or less for core data                      |
| Recovery time  | 8 hours or less for the core service                |

These are operating objectives. An unusually broad incident or a dependency outside our control may take longer to recover.

## Subprocessors

We use a small set of specialist providers to operate Plainrouter. Each receives only the data needed for its service. Customers can request our current named register and data processing agreement.

| Service                    | Purpose                                                                 | Data                                                       | Region                     |
| -------------------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------- | -------------------------- |
| Cloud infrastructure       | Application hosting, managed database, storage, and backups             | Account, configuration, signal, campaign, and service data | European Union             |
| Network and delivery       | DNS, traffic delivery, abuse prevention, and availability               | IP address, request metadata, and security events          | Global edge; EU origin     |
| Transactional email        | Account verification, invitations, password resets, and service notices | Name, email address, and message delivery metadata         | EU or safeguarded transfer |
| Optional sign-in providers | Customer-selected social sign-in                                        | Provider ID, name, email address, and profile image        | Provider dependent         |
| Product analytics          | Product usage analytics                                                 | Pseudonymous usage events and page URLs                    | EU                         |

Advertising networks connected by a customer may receive campaign, audience, conversion-event, and reporting data under that customer's direction. Depending on the relationship, those networks may act as independent recipients rather than Plainrouter subprocessors.

## Incident response

We follow this response process with clear ownership, communication paths, and decision points.

1. **Triage:** Confirm the report, classify severity, preserve evidence, and assign an incident lead.
2. **Contain:** Limit exposure, revoke affected credentials, isolate systems, and keep essential service running during containment.
3. **Recover:** Remove the cause, restore service, validate integrity, and increase monitoring.
4. **Communicate:** Notify affected customers and authorities without undue delay when law or risk requires it.
5. **Improve:** Document the timeline and root cause, then track corrective actions to completion.

## A practical European baseline

Our baseline is informed by the EU Agency for Cybersecurity's 12-step guide for SMEs, which covers responsibility, risk, people, access, patching, networks, monitoring, backups, and incident preparation.

We use the guide to inform our security choices and adapt safeguards as the service and its risks change.

[Read the ENISA guide](https://www.enisa.europa.eu/publications/cybersecurity-guide-for-smes)

## Report a security issue

Send a clear description and steps to reproduce. Please avoid accessing other people's data or disrupting the service while testing. Email [hello@plainrouter.com](mailto:hello@plainrouter.com).

For integration boundaries and authentication behavior, use the [documentation](https://plainrouter.com/docs) and [API Docs](https://plainrouter.com/docs/api/conversions).