Security

How we protect your code and your customers' data.

We work inside our clients' repositories and cloud accounts every day. This page describes the practices we follow to keep that access safe. If your security team has a questionnaire, send it over.

Access control

Least privilege by default. Staff get access only to the client accounts and systems they work on, and only at the level the task needs.
Single sign-on and multi-factor authentication are required for all staff accounts on company systems, including email, source control and cloud consoles.
Per-client credentials. We use separate accounts or roles for each client and never share credentials between clients or between people.
Access is reviewed when someone changes projects and removed promptly when an engagement ends or a person leaves the company.
Secrets are stored in a password manager or the client's secrets store, never in source code, chat or email.

Access reviews

Access that isn't reviewed tends to accumulate. We check it on a fixed schedule and at every change in who is working on what.

Every quarter: Full review of staff access to company systems and to each client account. Anything not needed for current work is removed, and the review is recorded.
When someone changes projects: Access to the previous client's systems is removed the same week, unless the client asks for continuity.
When an engagement ends: We remove our accounts, keys and tokens from your systems and confirm in writing, or hand removal over to your admin with a checklist.
When a person leaves: Company accounts are disabled on their last day, and client access is revoked or rotated, including shared secrets they could see.

Code and data handling

Client code lives only in the client's own repositories. We don't keep copies in company repositories or personal accounts.
No production data on laptops. Development and testing use seeded or anonymized data. When a production issue requires looking at real data, it is done inside the client's environment with their permission.
Company laptops use full-disk encryption, automatic screen lock and current operating system updates.
When an engagement ends, we remove our access and delete any client material held on company systems, except records we are required to keep for legal or accounting reasons.

Data lifecycle

How data moves through our services, from the moment we receive it to the moment it is deleted. Retention periods match our Privacy Policy.

Collection
We collect only what the work needs: account and billing details for our own services, and access to your systems for development work. In apps we build, we design forms and analytics to collect the minimum personal data, and document what is collected and why.
Storage
Client code stays in your repositories. Product data is stored on AWS, encrypted in transit and at rest. Credentials live in a password manager or your secrets store. Production data does not go on laptops.
Use
Data is used only to provide and support the service it was given for. Staff access it on a need-to-know basis, and we don't use client data to train AI models.
Retention
Account information is kept for the life of the account and up to 90 days after closure; server logs for up to 90 days; billing records for seven years, as tax law requires. Copilot conversation history is kept for the period the client configures.
Deletion
When a product subscription ends, you have 30 days to export your data, and product data is deleted within 30 days after that. When a development engagement ends, client material on company systems is deleted, except records we must keep by law.

Secure development lifecycle

Security checks are part of the normal path every change takes, not a separate audit at the end. The same steps apply to client work and to our own products.

Spec
Each request's spec notes security-relevant changes: new data collected, new permissions, new third-party services or changes to authentication.
Build
Engineers follow secure coding practices informed by the OWASP Application Security Verification Standard (ASVS): input validation, parameterized queries, output encoding and least-privilege service accounts.
Automated checks
Every pull request runs tests, type checks, linting, dependency vulnerability scanning and secret scanning in CI. A failing check blocks the merge.
Code review
A second engineer reviews every change before it merges, including authorization, data exposure and error handling, not only whether it works.
Staging
Changes run in a staging environment that mirrors production, with test data, before you approve them.
Release
Production deploys are automated, logged and reversible. Infrastructure changes go through the same review as application code.
Maintain
Dependencies are kept current. Patches for critical vulnerabilities in your stack go to the top of your queue at no extra cost.

Infrastructure

Papel Cloud, Papel Monitor and Papel Copilot run on Amazon Web Services (AWS).
Data in transit is encrypted with TLS 1.2 or higher. Plain HTTP requests are redirected to HTTPS.
Data at rest is encrypted using AWS-managed encryption for databases, storage volumes, backups and object storage.
Production environments are separated from staging and development, and infrastructure changes are made through code review rather than by hand.
Databases are backed up daily, and backups are encrypted.

Backup and recovery

Databases we host are backed up automatically every day, and backups are encrypted at rest.
Papel Cloud Pro and higher plans add point-in-time restore, so a database can be restored to a moment within the retention window, seven days on Pro.
Backups are stored separately from the systems they protect, so a failure of one environment doesn't take its backups with it.
We test restoring from backup on a regular schedule, and after any significant change to how a database is set up, instead of assuming backups work.
Each production application we run has a written runbook covering how to restore service and data, who does it and how you are kept informed.
For applications in your own cloud account, we set up and document backups in your account. You keep control of retention and who can restore.

Uptime commitments and service credits for eligible hosted plans are set out in our Service Level Agreement.

AI data handling

Papel Copilot and the AI features we build for clients use Anthropic's Claude models through the Anthropic API, under Anthropic's commercial terms.

Under those commercial terms, Anthropic does not use inputs or outputs sent through the API to train its models.
We don't send client code, client data or your customers' data to any AI model unless the client has opted in for that specific use, in writing or through a product setting.
In Papel Copilot, the assistant only receives the content a customer chooses to connect, such as help center articles, and the questions their users ask.
Where AI features are built into a client's app, we document what data is sent to the model, why, and how long it is retained, so the client can describe it in their own privacy policy.

Shared responsibilities

Security depends on both of us. This table shows who is responsible for what in a typical development subscription. A signed agreement can assign responsibilities differently.

Security responsibilities of PapelSoftware and the client
Area	PapelSoftware	You
Accounts and access	Use individual accounts with MFA for every staff member; review and remove access on the schedule above.	Own the accounts; grant access through your identity provider where possible; tell us when your own staff change.
Source code	Commit through reviewed pull requests; keep secrets out of code; keep dependencies patched.	Own the repositories and their settings, such as branch protection and who can merge.
Cloud infrastructure	On Papel Cloud: run, patch and monitor the platform. In your account: configure it through reviewed code.	In your own cloud account: hold the root account, billing and the final say on access.
Data	Handle data only as instructed, encrypt it, and delete it at the end of the engagement.	Decide what data your product collects, have a lawful basis for it, and keep your own backups of data you supply.
End-user privacy and compliance	Document what personal data the software processes, so you can describe it accurately.	Publish privacy notices, collect consents and meet the laws that apply to your business and industry.
Third-party services	Integrate them securely and tell you what data each one receives.	Hold the contracts and accounts for services such as payment, email or analytics providers.
Incidents	Detect, respond, notify your designated contact and write a post-incident summary.	Keep a current security contact on file and report anything suspicious to us promptly.

Incident response and notification

We keep a written incident response process covering how a security event is reported, who leads the response, how it is contained and how affected systems are restored.

If we confirm a security incident that affects your data or systems, we will notify your designated contact without undue delay, tell you what we know and what we are doing about it, and keep you updated until it is resolved. After an incident, we share a written summary of the cause and the changes made to prevent it from happening again.

Notification timelines in a signed agreement, such as a data processing addendum, take precedence over this page.

Vulnerability disclosure

If you believe you've found a security vulnerability in our website or products, email [email protected] with a description, the steps to reproduce it and any proof-of-concept code.

We will acknowledge your report, investigate it and keep you informed as we work on a fix. Please give us reasonable time to resolve the issue before disclosing it publicly, and don't access or change data that isn't yours, degrade our services or use social engineering. We won't take legal action against good-faith research that follows these guidelines.

We don't currently run a paid bug bounty program.

Compliance and security reviews

We don't currently hold third-party security certifications or attestations, such as SOC 2 or ISO 27001, and we don't claim to. What we can show you is how we actually work: the practices on this page, written answers to your questions and an engineer to talk them through.

Security questionnaires: We complete vendor security questionnaires in writing, whether a standard format or your own. Questionnaires are part of the Enterprise plan; on other plans, ask and we'll tell you what we can provide.
Data processing addendum: A DPA covering how we process personal data on your behalf, including subprocessors and breach notification, is available. We can sign ours or review yours.
Payment card data: Payments for our services are handled by Stripe, and we never store full card numbers. In apps we build, we use the payment processor's hosted fields or checkout so card data doesn't touch your servers.
Regulated data: If your product handles health, financial or children's data, tell us before work starts. We'll confirm in writing whether we can support your requirements, and decline if we can't.

Subprocessors

These third parties process data on our behalf to deliver our services. We review each provider's security practices before using them.

Provider	Purpose
Amazon Web Services, Inc.	Cloud hosting and storage
Anthropic, PBC	AI model provider for Papel Copilot
Stripe, Inc.	Payment processing
Google LLC (Google Workspace)	Email and documents

How we handle personal information is described in our Privacy Policy. Questions about privacy go to [email protected].

Have a security questionnaire?

Send it to our security team. We'll answer it in writing and set up a call with an engineer if your reviewers want one.

Contact security How we work