1. Scope
An incident is anything that makes an application unavailable, makes it behave incorrectly in a way a customer would care about, or exposes data to someone who should not have it.
2. How we learn of an incident
Today, primarily from the people using the applications. We are a young company, and we state that plainly rather than describing monitoring we do not have.
The other sources in use:
- Application logs, which record every refused request, every skipped delivery and every failure to reach a third party.
- A scheduled job failing, such as a backup.
- Notices from the platforms our applications integrate with.
Automated alerting is not yet in place. Each application exposes a health endpoint suitable for an external uptime check, and adding external monitoring and error alerting is planned work. Until it lands, the times in §4 start from the moment a person becomes aware, which is the only honest way to state them.
3. Who responds
Our support team is first responder and owns the incident until it is resolved or handed to an engineer. There is no formal on-call rotation; the team operates during business hours and is reachable at dev@appexpertly.com.
4. Response times
- Acknowledge and begin work — 30 to 60 minutes from becoming aware.
- Assess whether data is affected — within 4 hours of acknowledgement.
- Notify affected customers, where data is affected — within 48 hours of confirming it.
- Written summary — within 5 business days of resolution.
The 48 hours is deliberate. As a processor we must tell you without undue delay so that you can meet your own regulatory deadline, which is typically 72 hours from your becoming aware. Telling you within 48 leaves you time to act rather than consuming it.
5. Handling an incident
Contain first. The mechanisms available are deliberately blunt and fast:
- Roll back to the previously deployed image, from CI, with no rebuild.
- Rotate a credential. Inbound secrets and the data-encryption key both rotate without an outage, because a previous value is accepted during changeover.
- Disconnect an integration for one customer, stopping all processing for them while leaving their data intact.
- Purge one customer's records entirely, where that is the right answer.
- Restore from backup. Logical dumps run on a schedule and the restore procedure is documented, down to the exact commands.
Then establish what happened — what was reachable, by whom, for how long, and which customers are affected. Application logs and the event and delivery records are the evidence. Then fix and verify, and only then close.
6. What we tell you
What happened, when it started and when it stopped, what data of yours was involved, what we did about it, and what if anything you need to do. If we do not yet know one of those, we say so rather than waiting until we do.
We do not send an apology in place of a fact.
7. Afterwards
Every incident that affected a customer gets a written review: what happened, why, what would have caught it earlier, and what changed as a result. Where it exposes a weakness in the code, it becomes a numbered finding under Vulnerability Management and takes a severity and a remediation target like any other.
Reviews look for the missing control, not the responsible person.
8. Reporting one to us
dev@appexpertly.com. Tell us what you saw and when. If you believe data has been exposed, say so in the subject line so it is not queued behind ordinary support.