Incident Response
How CostGuard prepares for and responds to security incidents.
This page describes the principles CostGuard follows when something looks wrong. It stays at the level of process on purpose: it publishes no internal procedure, no infrastructure detail, and no detection logic. Not every event is a security incident, and the assessment step exists to tell those apart.
Detection and assessment
Signals can come from application and infrastructure monitoring, from a report sent through the Contact page, from a customer, or from a platform notice. Each signal is triaged to decide whether it is an operational fault, a false positive, or a suspected security incident, and to judge what data and which accounts could be affected.
Containment and remediation
When a signal is treated as a suspected incident, the first goal is to limit its effect: restricting the affected path, rotating credentials where that applies, and stopping the behavior that caused it. Remediation then addresses the underlying cause, and the fix follows the normal review and deployment process.
Customer communication
Where an incident affects customer data or the availability of the service, CostGuard aims to inform affected customers with what is known, what is being done, and what action the customer may need to take. Whether a particular event calls for customer notification depends on its nature and on the requirements that apply.
Review and improvement
After an incident is closed, the team reviews what happened and what would reduce the chance of a repeat, and folds the outcome back into the product, the tests, and the operational practice. The Service Status page remains the public place for availability information.
What this page is not
This page describes a process, not a service commitment. It states no response time, no notification deadline, and no resolution time, and it is not certification evidence or audit evidence. Any timing commitment that applies to your account comes from the agreement that applies to your account.