How we protect data —
and what we don't claim.

The honest framing first

Most security pages are written to reassure. This one is written to be checked. Claudphic is a small company, and some controls a large vendor would have — a dedicated security team, a SOC 2 report, 24/7 monitoring staff — we do not have yet. Saying so costs us something and is the only way the rest of the page is worth reading.

What we do have is a deliberately small attack surface, a short list of people with access, and no appetite for holding data we do not need.

Encryption

• In transit. Every Claudphic property is served over HTTPS with modern TLS. HTTP requests are redirected, and HSTS is set on production so a browser will not downgrade.
• At rest. Application databases and backups are encrypted at rest by the hosting platform.
• Secrets. Credentials and API keys live in environment configuration outside the web root and outside version control. They are never committed, never logged, and never sent in support correspondence.
• Identifiers sent to advertising platforms are hashed before transmission. Raw email addresses and phone numbers are not sent to Google Ads or Meta.

Access control

Access to production systems and customer data is limited to named individuals who need it to operate the service. Today that is a very short list. Every account uses multi-factor authentication. Access is granted on a least-privilege basis and removed the day it stops being necessary.

We do not browse customer workspaces out of curiosity. Support staff access a customer's data only when the customer has asked for help with a specific problem, and only as far as that problem requires.

What we deliberately do not hold

The cheapest way to protect data is not to have it.

• No card numbers. Payments are handled by a payment processor; card details never reach Claudphic systems.
• No passwords in readable form. Authentication secrets are stored using a modern one-way hash.
• No tracking profiles of website visitors. claudphic.com runs no advertising cookies, no third-party analytics and no session recording. See the cookie policy.
• No sensitive categories. Claudphic Ads is not intended for health, biometric, financial-account or other sensitive personal data, and customers are asked not to upload it. Advertising platforms prohibit transmitting it, and so do we.

Application security

• Dependencies are kept current and reviewed when an advisory affects something we run.
• Standard protective headers are set: content-type options, frame options, referrer policy and a restrictive permissions policy.
• Input is validated and database access is parameterised; output is escaped on render.
• Session and form tokens are used for state-changing requests.
• Framework internals and configuration directories are blocked at the web server rather than relying on the application alone.

Backups and recovery

Application data is backed up on a regular schedule, encrypted, and retained on a rotating window of roughly ninety days before expiring. Backups are what make a deletion request take up to ninety days to become absolute, and the data deletion page explains that trade-off rather than glossing over it.

Reporting a vulnerability

If you find a security problem, please tell us. Send it to the address on the contact page with enough detail to reproduce it.

• We acknowledge within two working days.
• We will tell you what we found and when it is fixed.
• Good-faith research is welcome and will never be met with legal threats.
• Please do not access, modify or exfiltrate data belonging to other people, and please give us a reasonable window to fix the issue before publishing.

We do not currently run a paid bug bounty. We will credit you publicly if you want that, and we will say so plainly if a report does not qualify.

If there is a breach

We will tell you. Specifically: affected customers are notified without undue delay and in any case within 72 hours of us becoming aware of a personal data breach, along with what happened, which categories of data were involved, what we have done, and what you should do. Where the law requires it, we notify the relevant authority in parallel — in India, the Data Protection Board.

We will not wait until we have a complete picture before telling you something has happened. A partial, prompt notification is more useful to you than a polished, late one.

Who else touches the data

A handful of service providers necessarily process data on our behalf — hosting, email, domain infrastructure, payments, and the advertising platforms our software integrates with. Each is named, with its purpose and processing location, on the sub-processors page, and customers get at least thirty days' notice before a new one is added.