Security at PulseSignal

We do not claim certifications we have not earned. Our current posture is:

• SOC 2-aligned controls: we follow SOC 2 Trust Services Criteria internally (security, availability, confidentiality, processing integrity). A formal AICPA audit is not yet in scope; we will engage an auditor once paying-customer revenue justifies the cost. We do not claim a SOC 2 report.
• ISO 27001, HIPAA, PCI-DSS, FedRAMP: not in scope today. We will update this page if and when we begin a formal engagement.
• GDPR and UK GDPR: we operate under the lawful bases described in our Privacy Policy, and we sign Standard Contractual Clauses through each sub-processor’s data-processing addendum.
• Security testing: we run continuous internal security testing (OWASP ZAP automated scans, Nuclei template-based vulnerability scans, Bandit + Semgrep static analysis, dependency-vulnerability scans via pip-audit + npm audit, plus manual reviews against the OWASP Top 10). Findings + fixes are tracked in our internal master list; a third-party penetration-test engagement will follow paying-customer revenue.

• In transit: all public endpoints (pulsesignal.co, www.pulsesignal.co, app.pulsesignal.co, and the API) require TLS 1.3 with modern cipher suites. HTTP requests are redirected to HTTPS, HSTS is enabled with a 12-month max-age, and we do not accept legacy SSL or TLS 1.0/1.1.
• At rest: customer data, search history, alert configuration, and intelligence observations are stored on infrastructure with AES-256 disk-level encryption. Backups inherit the same encryption and are rotated on a fixed schedule.
• Field-level encryption: secrets that grant access to your downstream systems (Slack delivery tokens, outbound webhook signing keys, API-key bearer tokens) are stored using application-level encryption with envelope keys managed by our cloud key-management service. Plaintext is only materialised in memory at the moment of delivery.
• Passwords: stored using a memory-hard hashing function (Argon2id) with per-user salts. We never store password plaintext and we cannot recover a password on your behalf.

• Two-factor authentication (2FA) is available to every account on every paid tier today, using time-based one-time passwords (TOTP) from any standard authenticator app.
• SSO via SAML 2.0 and OIDC is available on the Business tier and above. SCIM user provisioning is on the Business+ roadmap; reach out if you need it sooner.
• Sessions are bound to the device that signed in. You can revoke any active session from your session settings. Suspicious-login email alerts are on by default.
• Internal access to production systems is gated by SSO with hardware-key second factor, granted on a least-privilege basis, and logged. Production database access is broker-mediated; ad-hoc reads require an auditable session.

We rely on a small number of vetted service providers to run PulseSignal. The complete list, what each one does, where they are located, and the safeguards we have in place with them, is maintained at /privacy/sub-processors. Material additions are announced on that page and by email to active customers at least 30 days before the new provider begins processing customer data.

Our primary processing region is US-East (Northern Virginia). All customer data is written to that region by default. Backups are stored in a separate availability zone within the same region.

An EU mirror (primary processing in the European Union, currently planned for Frankfurt) is on the roadmap for the Business+ tier. It is not available today. We will update this page, and notify Business+ customers by email, when the EU region is generally available. Until then, EU-based customers continue to rely on the Standard Contractual Clauses incorporated into each sub-processor’s DPA.

• Code changes are reviewed by at least one engineer other than the author before merge.
• The mainline test suite runs on every pull request; deployments do not proceed if tests fail.
• Third-party dependency vulnerabilities are scanned on each build; high-severity findings are triaged within the SLA in section 8.
• Secrets are managed through our cloud secret-manager; no secrets are stored in source control. We rotate long-lived credentials on a fixed schedule and on any role change.
• Structured audit logs are emitted for authentication, billing, configuration changes, and exports. Logs are retained for one year on a separate index.

If you believe you have found a security issue in PulseSignal, please email security@pulsesignal.co. For sensitive reports you can encrypt to our PGP key (fingerprint published at /.well-known/security.txt); the key is rotated annually.

Please give us a reasonable window to investigate and remediate before public disclosure. In return, we commit to:

• Acknowledge your report within two business days.
• Keep you informed of progress at least weekly until the issue is resolved.
• Credit you publicly once the fix has shipped, if you would like to be credited.
• Not pursue legal action against good-faith research conducted within the scope below.

In scope: pulsesignal.co, www.pulsesignal.co, app.pulsesignal.co, and the public REST API at api.pulsesignal.co. Test against your own account only.

Out of scope: denial-of-service attacks, social-engineering or phishing of PulseSignal employees, physical attacks, automated scanner output without a working proof-of-concept, missing best-practice HTTP headers without a demonstrable impact, and any testing against customer accounts other than your own.

We classify incidents on a four-tier severity scale. The acknowledgement and resolution targets below apply to confirmed reports from customers and from external researchers.

If an incident affects personal data of EU, UK, or Swiss residents, we will notify the relevant supervisory authority and affected data subjects in line with our legal obligations and, where applicable, within 72 hours of becoming aware of it. Customer-side notifications go to the primary billing contact and to any security contact you have configured.

We run a private disclosure-only programme today: there is no monetary reward, but every valid report receives acknowledgement, a status update through to resolution, and (with your consent) public credit. Reports are submitted by email to security@pulsesignal.co.

We intend to move to a paid HackerOne programme once paying-customer revenue justifies the engagement. We will publish the scope, severity-to-bounty table, and safe-harbour terms on this page when the paid programme opens.

• Production data is backed up daily; backups are encrypted with the same key material as the live store and are tested on a quarterly restore exercise.
• Our target recovery-point objective (RPO) is 24 hours for customer-configuration data and 1 hour for billing records.
• Our target recovery-time objective (RTO) is 8 hours for the core read path (search, dashboards, exports) and 24 hours for ingestion catch-up.
• Status, scheduled maintenance, and incident notices are posted at status.pulsesignal.co.

• Background checks are performed on every employee with production access, where permitted by local law.
• All employees complete security and privacy training at onboarding and on an annual refresh.
• Laptops are managed devices with full-disk encryption, automated patching, and screen-lock enforcement.
• Access to production is revoked on the same business day that an employee leaves the company.

Security disclosures: security@pulsesignal.co.
Privacy questions: privacy@pulsesignal.co.
Product and support: hello@pulsesignal.co.
DPA, security questionnaire, audit-report requests (Business+): email privacy@pulsesignal.co with your account name.

We will update this page as our controls, sub-processors, and certification posture change. The effective date at the top reflects the most recent revision. Material changes are announced by email to active customers at least 30 days before they take effect.