---
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-09-14
---

# Plainrouter Security Policy

Plainrouter protects first-party signals and advertising-account credentials with layered safeguards. Human approval is required for supported creative changes: JPEG/PNG uploads and paused Meta ad copies. Budget and status recommendations cannot execute in this release.

## Security at a glance

- Data region: **European Union**
- Baseline: **ENISA-informed**
- Action authority: **Human approval**
- Last reviewed: **August 2026**

## How we protect the service

Our controls are intentionally practical: isolate sensitive systems, minimize access, protect credentials and event data, govern provider writes, and make recovery a routine operation.

### 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; only owners can manage critical workspace settings and ad-platform connections.
- Workspace keys have Read or Write tiers. Management keys use one fixed management ability. Authentication endpoints are rate-limited.
- Privileged internal access is limited to people who need it, reviewed regularly, and removed promptly.

### Backups and recovery

Recovery is designed in, not left to hope.

- Production data is backed up automatically, encrypted, and retained separately from the live environment.
- Restore procedures are tested regularly and after material infrastructure changes.
- 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.

- Changes are peer-reviewed and tested 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 and repeatable practice.

- Security responsibilities, onboarding, offboarding, and acceptable-use expectations are documented.
- Phishing awareness and secure handling of credentials are part of recurring team training.
- Risks and controls are reviewed at least annually and whenever the product or threat landscape changes materially.

## Backups that can be restored

A backup is only useful if it is separate, encrypted, and recoverable. Our continuity process is built around all three.

| Target         | Objective                                           |
| -------------- | --------------------------------------------------- |
| Backup cadence | Daily automated production snapshots                |
| Recovery point | 24 hours or less for core data                      |
| Recovery time  | 8 hours or less for the core service                |
| Restore checks | Quarterly and after material infrastructure changes |

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 and is reviewed before use. 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         |

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 maintain a documented response plan 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: assign responsibility, manage risk, train people, control access, patch systems, protect networks, monitor, secure backups, and prepare for incidents.

ENISA publishes guidance; it does not certify Plainrouter. We do not use alignment as a substitute for independent assurance, and we will publish formal audit results only when they exist.

[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. Use the contact option on the HTML security page.

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