Practices stated, disclosure welcomed.
How security is run, what protects data in transit and at rest, how access is controlled, and exactly how to report a vulnerability with what happens after you do. Certification status is stated honestly, including what has not started.
Stated, not implied
The practices, in order of importance.
How security is run
As an engineering function, not a document: controls ship in code, reviews precede releases, and the disclosure channel feeds fixes directly into the same pipeline.
Data protection
TLS for data in transit, encryption at rest for stored data, and managed keys with rotation. Bid path data is kept to the categories named in the privacy notice and retained on published schedules.
Access control
Multi-factor authentication on internal and dashboard access, least-privilege roles, and audit logging on privileged actions. Access reviews are part of the release cycle, not an annual event.
Monitoring and testing
Vulnerability scanning runs continuously against infrastructure. Penetration testing cadence and scope are shared with enterprise customers during security review, where the details can be kept current rather than marketing-frozen.
Secure development lifecycle
Security requirements are part of the design, changes pass review before merge, every deployment is traceable through the pipeline, and each release maps back to the change that produced it.
Continuity and recovery
Business continuity and disaster recovery procedures are maintained for the auction, SSAI delivery and reporting, and exercised before they are needed. Test cadence and results are shared during enterprise security review.
Vendor risk
Sub-processors are assessed before onboarding, bound to security obligations in their contracts, and listed in the DPA with notice before additions. Their compliance is part of our review cycle, not an assumption.
Logging and detection
Security-relevant events across the auction, dashboards and infrastructure are logged centrally, retained on the schedule in the DPA, and monitored so that anomalous access or behavior surfaces as an alert rather than as a quarterly surprise.
Incident severity
Incidents are triaged against a published severity scale, from low, with no data or service impact, to critical, affecting customer data or the auction path. Severity decides the notification path, the response team and the postmortem depth, so response effort tracks actual impact.
How to report, what we commit to.
The disclosure process
Report
Email security@skyboosts.com or use the security route on the contact form. Include reproduction steps, affected endpoints and impact. Write to us before public disclosure.
Acknowledge
We acknowledge reports within one business day and assign a tracking reference.
Fix and verify
Confirmed issues are prioritized by severity, fixed, and verified against your reproduction. You receive the outcome and the fix timeline.
Credit
Researchers who report responsibly are credited on request in our disclosure notes.
Incident notification
Confirmed incidents affecting customer data or service are notified without undue delay through the dashboard and direct contact, with impact description, containment status and remediation steps, followed by a written postmortem for material incidents.
Current status, honestly
SOC 2 and comparable certifications: the current state for each, including in progress and not yet started, is shared during enterprise security review rather than claimed here. Nothing is listed as held before it is issued.
Disclose first. We do the rest.
Found something? Send reproduction steps and the affected area. Acknowledgement lands within one business day.
One business day acknowledgement · credit on request