Access control
Customer data endpoints require an access key sent through the X-API-Key header. New customer keys are verified with hash-based records, unknown keys are rejected before account intelligence is returned, and dashboard pages keep entered keys in browser-session storage only.
Source permissions
The platform uses official APIs, public datasets, licensed providers, or customer-provided data where the permitted use is clear. LinkedIn is restricted unless there is approved access, and Adzuna-derived signals are gated for paid commercial use until written permission or a suitable licence is in place.
Evidence standard
Signals are scored with source quality, confidence, and buyer-fit checks. Hiring signals are treated as intent indicators, not proof of buying intent, and thin-evidence records are held back from guided customer demos.
Budget transparency
Budget estimates are shown only when evidence supports them. Otherwise the app displays budget evidence pending instead of inventing a value.
Retention
Active intent evidence is designed around a 90-day freshness window. Pilot records, opt-out records, invoices, and security logs may be kept longer where needed for legal, billing, security, or suppression-list reasons.
Browser protection
Browser responses include host validation and security headers for frame blocking, MIME sniffing, referrer leakage, cross-origin boundaries, permissions, content security policy, and HSTS in production.
Operational contacts
For privacy, deletion, correction, opt-out, or vulnerability-reporting requests, use compliance@cybersignals.io.
For pilot support and signal-quality feedback, use the support contact provided in your onboarding email. Security reporting metadata is available at /.well-known/security.txt.