Trust & security

Data we process

Depending on how you use PentSeal, the service processes:

• Account information such as your email address, name and role
• Engagement records: targets you add, the scope you define, rules of engagement, and signed authorization records
• Ownership-verification tokens you publish for DNS or HTTP challenges
• Scan results and findings, including CVSS/CWE scoring and severity ratings
• Evidence you attach to findings, and the hash-chained custody record built from it
• Integration credentials you add — stored server-side and never included in the integrations list (an admin can read back the values they configured); application-layer encryption for these values is not yet enabled
• Audit-trail events: who did what, when, and to which resource, with sensitive fields redacted
• Messages you send through the contact, demo and lead forms

We do not intentionally collect payment card data (Stripe holds it) or protected health information. Please do not enter data that you are not permitted to store with us — see Terms §4.

Where things run

The application runs on Vercel's serverless platform. The security checks PentSeal performs are built-in implementations that execute inside that runtime and make outbound probes — TLS, DNS, HTTP and port checks — to the targets you have authorized. Scans are not routed through third-party scanning engines, and PentSeal will not run checks against a target until ownership is verified and the engagement's authorization record is in place.

Authorized testing is the product

PentSeal exists to keep testing inside its authorization. Concretely: targets must pass an ownership challenge (DNS TXT or HTTP file) before they can be tested; scope, rules of engagement and the testing window are captured and signed as one record; actions are gated on that record at run time; and an append-only audit trail plus a hash-chained evidence custody record let you demonstrate afterward exactly what was authorized, what ran, and what was found. Testing without provable authorization is treated as misuse, per Terms §1.

How we protect data

• Authentication via session cookies marked HttpOnly and Secure, with rate limiting and lockout backoff on repeated failures
• Role-based access control (admin, analyst, viewer) enforced server-side, with every request scoped to the caller's tenant
• Schema validation on API inputs
• Application-layer field-level encryption (AES-256-GCM) for sensitive fields such as contact details, credentials and verification tokens — implemented in the codebase but not yet enabled in production; until it is switched on, data is protected in transit (HTTPS/TLS) between the app and the datastore
• TLS 1.2/1.3 in transit with HSTS; certificates managed and auto-renewed by the hosting platform
• Structured audit logging with PII redaction
• Supply-chain controls: dependency pinning, secret scanning, vulnerability scanning and SBOM generation in CI

Multi-factor authentication and SSO are roadmap items, not features of the current build — we would rather say that than imply they exist.

Data residency

Data is stored in the configured region of the managed Redis provider (Upstash). Regional pinning per customer is a roadmap item, not a current guarantee; if residency is a hard requirement for your engagement, ask us about the current deployment region before you commit.

Providers we rely on

The following services process data on our behalf:

Payment processing is handled by Stripe when billing is enabled; card details never reach PentSeal servers. We keep this table limited to providers actually wired into the service and update it as that changes.

Deleting your data

Engagement, asset, finding and evidence data you enter belongs to you. There is currently no self-serve account deletion; request deletion through the contact page and we will remove your workspace's engagement, finding and evidence records from the datastore and confirm when done.

Report a security issue

Found a security vulnerability in PentSeal? Email security@pentseal.com or use the contact page. We review all good-faith reports and will keep you informed of progress. We do not run a paid bug-bounty program at this time.

Status and incidents

Component health and measured availability history are published on the public status page (JSON feed at /api/status). The uptime figures there are recorded by PentSeal probing itself — they are published as measured evidence, not as an independent attestation. If an incident affects your data, we will notify affected customers directly.

Certifications and compliance

PentSeal does not currently hold SOC 2, ISO 27001, or other third-party certifications. The honest limits of the service are described in our Terms of Service. Our compliance program is being built against SOC 2 and PCI DSS control frameworks, and we will update this page as it develops.

Service limits

Features described as “not yet available” in the documentation may change, and no service-level agreement applies except where one is agreed in writing. The availability target shown on the status page is an internal engineering objective, not a contractual commitment. Check results and exported reports reflect what was tested at the time they ran — they are not a guarantee that a system is secure, and they are not an attestation or certification.