Incident response.
How Sliick detects, contains, and responds to a cyber security incident. Owned by Sliick Pty Ltd. See also the Personal Information Breach Response Plan.
1. Purpose and scope
This plan sets out how Sliick detects, contains, and responds to a cyber security incident affecting:
- Sliick's Salesforce managed packages (Docs, Files, Photos, Charts, Forms) and the customer orgs they run in
- Infrastructure Sliick operates directly: the sliick.com website and APIs (Cloudflare Workers), Sliick Cloud Storage (Cloudflare R2), and supporting services (GitHub source control and CI, Resend for transactional email)
It does not cover the security of a customer's own Salesforce org, or of a customer's own connected storage (Amazon S3, Azure, Google Cloud, SharePoint), which remain the customer's responsibility under their own security programs.
2. Definitions
A security incident is any confirmed or reasonably suspected event that compromises the confidentiality, integrity, or availability of Sliick-operated infrastructure or the data it processes. This includes unauthorised access, credential compromise, malware, denial of service, misconfiguration exposing data, and vulnerabilities in Sliick-published code that are being or could be actively exploited.
Severity is classified on discovery and re-assessed as facts emerge:
| Severity | Definition | Example |
|---|---|---|
| Critical | Confirmed unauthorised access to, or exposure of, customer data | A misconfigured R2 bucket found publicly listable |
| High | Active exploitation attempt or a vulnerability with a realistic path to customer data | A credential-broker endpoint returning tokens scoped too broadly |
| Medium | Suspicious activity with no confirmed data impact | Repeated failed auth attempts against an admin endpoint |
| Low | Isolated anomaly, no plausible data impact | A single unexplained error spike with no security signature |
3. Roles and responsibilities
Sliick is a small team. The Incident Lead holds end-to-end accountability rather than delegating across a dedicated security function.
- Incident Lead (Jerry Huang): triages, classifies severity, coordinates containment and remediation, owns customer and regulator notification, and signs off closure.
- External support as needed: Cloudflare support (infrastructure-level issues), Salesforce support and AppExchange Security Review (managed package or platform-level issues), and legal counsel for notification obligations on Critical or High incidents.
4. Detection and reporting
Incidents may be identified through:
- Cloudflare Workers and R2 logs and alerting
- GitHub security alerts (dependency and secret scanning) on the source repositories
- Salesforce AppExchange Security Review findings or Salesforce-reported issues
- A customer or member of the public reporting a suspected issue via hello@sliick.com or the contact form
Anyone who suspects an incident, internally or externally, should report it to hello@sliick.com immediately. Reports are triaged within one business day, or sooner if the initial report indicates active, ongoing impact.
5. Response process
- Identify: confirm the incident, establish scope (which systems, which customers, what data), and assign severity.
- Contain: stop ongoing impact, revoking credentials, disabling an affected component, or blocking malicious traffic, without destroying evidence needed for root cause analysis.
- Eradicate: remove the root cause (patch the vulnerability, rotate compromised secrets, fix the misconfiguration).
- Recover: restore affected services, verify the fix, and monitor for recurrence before considering the incident closed.
- Notify: for any Critical or High incident confirmed to affect customer data, notify affected customers without undue delay and no later than 72 hours after Sliick becomes aware of the incident, consistent with the commitment in Sliick's Terms & Conditions. Where a notified incident involves personal information, notification follows Sliick's Personal Information Breach Response Plan.
- Communicate during the incident: for any incident under active response, affected customers receive an update at least daily, in addition to being notified immediately of any material change in status, until the incident is resolved. A day with no material change still gets a status update, not silence.
- Review: within two weeks of closure, document root cause, what worked, what didn't, and any resulting changes to this plan, infrastructure, or process.
6. Notification content
Where notification to a customer is required, it includes, to the extent known at the time:
- What happened and when it was discovered
- What data or systems were affected
- What Sliick has done and is doing in response
- What the customer may need to do, if anything
- A contact point for follow-up questions
Initial notification may be issued before every detail is confirmed, followed by updates as the investigation progresses, rather than delaying notification until the full picture is known.
7. Plan maintenance
This plan is reviewed at least annually and after any Critical or High incident. Material changes to Sliick's infrastructure (new subprocessors, new regions, new services) trigger an out-of-cycle review.
Contact us
If you have any questions about this plan, please contact us.