Skip to main content

Security Incident Response Policy

How we detect, respond to, and report security incidents

Effective Date: August 15, 2026

1. Scope

This policy covers security incidents affecting the Service, including:

●Unauthorized access to, disclosure of, alteration of, or destruction of customer data.
●Compromise of credentials, API keys, or infrastructure used to operate the Service.
●Control failures that make customer data reachable by a party who should not reach it, whether or not anyone did.
●Confirmed vulnerabilities in the Service that could lead to any of the above.

This policy does not cover service outages with no data impact, errors in OEM manual content or AI-generated answers (see the AI Disclaimer), or misuse of an Account by an authorized user of that Account (see the Acceptable Use Policy).

2. Incident Severity

SEV-1 — Confirmed breach. Customer data was accessed, disclosed, altered, or destroyed by an unauthorized party, or we reasonably believe it was.

SEV-2 — Exposure without confirmed access. A control failure made customer data reachable by an unauthorized party, with no evidence that it was reached.

SEV-3 — Vulnerability. A defect that could have led to a SEV-1 or SEV-2 incident, identified before any exposure occurred.

SEV-4 — Security-relevant event. An event with no customer data in scope.

Severity is assigned on what we can establish, not on what we hope. Where the available evidence does not allow us to rule out unauthorized access, the incident is treated as a SEV-1.

3. How Incidents Are Detected

●Automated database security advisors, run after every database migration. This is a written requirement in our engineering standards, not a convention — a migration is not considered complete until the advisors return clean.
●Platform logging and alerting from our database, hosting, and document indexing providers.
●Automated secret scanning across the codebase and commit history.
●Reports from customers, Users, and security researchers (see Section 7).
●Notifications from our subprocessors, listed in our Privacy Policy.
TroubleshootHD does not operate a 24/7 security operations centre. Detection is automated and continuous; human response is by a single responder during business hours in the Pacific time zone, with best effort outside them.

4. Response Procedure

1. Contain. Within 24 hours of becoming aware, remove the exposure — revoke access, disable the affected path, rotate the compromised credential. Containment takes priority over diagnosis, and over preserving the convenience of the fix.

2. Assess. Establish what data was in scope, whose it was, whether it included personal information, how long the exposure lasted, and whether access actually occurred. Where logs can answer the access question, we use them rather than reasoning from likelihood.

3. Notify. In accordance with Section 5.

4. Remediate. Fix the cause, not only the instance.

5. Record. Enter the incident in the breach register in accordance with Section 6.

6. Review. Identify the control that would have caught it sooner, and add it. An incident that produces no change to our detection or process is not closed.

5. Notification Commitment

We will notify affected customers within 72 hours of becoming aware of a SEV-1 or SEV-2 incident involving their data. This commitment applies whether or not the incident meets the statutory threshold for regulatory notification. The legal standard is "as soon as feasible" — 72 hours is our outer limit, not our target.

Notification is sent by email to the administrators of the affected Organization and to the individual Users whose personal information was involved. It will describe:

●What happened, and when we became aware of it.
●What data was involved, and whose.
●Whether we can establish that the data was actually accessed.
●What we have done to contain and remediate it.
●What, if anything, you should do.
●Who to contact for further detail.

If our assessment is incomplete at 72 hours, we notify anyway with what we know at that point, state plainly what is still unknown, and follow up. A late notification that is complete is worse than a prompt one that is honest about its gaps.

5.1 Regulatory Notification

Canada: we notify the Office of the Privacy Commissioner of Canada in accordance with the breach of security safeguards provisions of the Personal Information Protection and Electronic Documents Act (PIPEDA), where a breach creates a real risk of significant harm to an individual.

Australia: we notify the Office of the Australian Information Commissioner in accordance with the Notifiable Data Breaches scheme under the Privacy Act 1988 (Cth). Where we suspect an eligible data breach may have occurred, we complete our assessment within 30 days.

6. Breach Register

Every incident assessed at SEV-1, SEV-2, or SEV-3 is recorded, whether or not it resulted in notification. Each entry records the date of discovery, the nature of the incident, the data in scope, the determination reached on notification and the reasoning behind it, the remediation applied, and the control added.

Records are retained for at least 24 months from the date the incident is determined to have occurred, in accordance with PIPEDA's record-keeping requirement, and are provided to the Privacy Commissioner on request.

You may request the register entries for any incident affecting your Organization's data.

7. Reporting an Incident to Us

If you believe you have found a vulnerability in the Service, or that your Account or your Organization's data has been accessed without authorization, contact security@troubleshoothd.com.

We acknowledge security reports within 2 business days.

We do not currently operate a paid bug bounty program. We will not pursue legal action against anyone who reports a vulnerability in good faith, provided they do not access, modify, or retain data belonging to another customer, do not degrade the Service for others, and give us a reasonable opportunity to remediate before disclosing publicly.

8. Subprocessor Incidents

Our subprocessors are listed in our Privacy Policy. Where a subprocessor notifies us of an incident affecting customer data held on our behalf, the notification commitment in Section 5 applies from the point at which we are notified, and we will identify the subprocessor involved.

9. Current Limitations

Stated up front, for the same reason as the rest of this document:

●Response is by a single responder. There is no on-call rotation and no 24/7 human coverage.
●No third-party penetration test has been carried out to date.
●Multi-factor authentication is not currently enabled on customer Accounts.

These are a function of company stage, not of position. This policy is reviewed against them as the company grows.

10. Review of This Policy

This policy is reviewed annually, and after any SEV-1 or SEV-2 incident. We will notify you of material changes at least 30 days in advance by email or through the Service, consistent with our Privacy Policy.

11. Contact Information

Security reports and vulnerability disclosure: security@troubleshoothd.com

Privacy inquiries: privacy@troubleshoothd.com

General support: support@troubleshoothd.com

TroubleshootHD Inc. — https://www.troubleshoothd.com