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 automated security testing on every pull request and on demand. That covers Bandit + Semgrep static analysis (SAST), Trivy image scanning that fails the build on HIGH/CRITICAL findings, and on-demand OWASP ZAP and Nuclei scans, alongside manual reviews against the OWASP Top 10. Findings and 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.2 or higher with modern cipher suites. HTTP requests are redirected to HTTPS, HSTS is enabled with a max-age of at least 12 months, includeSubDomains, and preload, 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, API-key bearer tokens) are stored using AES-128 application-level (Fernet) encryption with a dedicated key held in our secret manager. Plaintext is only materialised in memory at the moment of delivery.
• Passwords: stored using bcrypt adaptive hashing (work factor 12) with per-user salts. We never store password plaintext and we cannot recover a password on your behalf.

• Two-factor authentication (2FA): available now. Enroll a time-based one-time-password (TOTP) authenticator app from your account settings and save one-time recovery codes. Once enabled, 2FA is enforced at every sign-in. The TOTP secret is encrypted at rest.
• 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.
• Production access requires a hardware-key second factor and is logged. Direct database connections are avoided in favor of an audited, broker-mediated 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 application and database are hosted in the United States (Ashburn, Virginia). All customer data is written to that US infrastructure by default, and backups are stored within the same region.

Where personal data is transferred from the European Economic Area, United Kingdom, or Switzerland to the United States, we rely on the European Commission Standard Contractual Clauses (Module 2 controller-to-processor and Module 3 processor-to-processor) for EU transfers, the UK International Data Transfer Addendum (IDTA) for UK transfers, and the EU SCCs as modified by the Swiss FDPIC for Swiss transfers, all incorporated into each sub-processor’s DPA. The full list of US-based sub-processors (billing, error monitoring, product analytics) is in the sub-processor list.

• Code changes are gated by automated checks that must pass before merge: static analysis, dependency and image security scans, and the full test suite.
• 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 90 days in our primary datastore.

The full Vulnerability Disclosure Program (scope, safe-harbor terms, acknowledgement and remediation SLAs, and a public-credit pathway) is published at /security/responsible-disclosure. That page is the canonical source of truth; the summary below restates the headline commitments so a security questionnaire can be answered without leaving this page.

If you believe you have found a security issue in PulseSignal, please email security@pulsesignal.co. Our contact and disclosure policy are also machine-readable at /.well-known/security.txt (RFC 9116). A PGP key is available on request to security@pulsesignal.co if you need to encrypt a sensitive report.

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 program 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 program once paying-customer revenue justifies the engagement. We will publish the scope, severity-to-bounty table, and safe-harbor terms on this page when the paid program opens.

• Production data is backed up daily; backups are encrypted with the same key material as the live store, and we verify restores using a documented restore-drill procedure which we are putting on a quarterly cadence.
• 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 on our status page.

• PulseSignal is operated in-house with no separate workforce holding standing access to production.
• Workstations are managed devices with full-disk encryption, automated patching, and screen-lock enforcement.
• Production access uses a hardware-key second factor and is logged; long-lived credentials are rotated on a fixed schedule.
• Should PulseSignal bring on staff or contractors with production access, this section will be updated to describe onboarding checks, security training, and same-day off-boarding before any such access is granted.

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.