TRUST CENTER · INCIDENT RESPONSE · NO ON-CALL, NO PRETENDING

When something breaks,
here is what happens.

wrxstack is run by a small team. There is no on-call rotation, no severity paging, and no incident history to publish. Atlas also has its own status page. This page describes how we intend to handle something going wrong and the breach notice rules the law sets. It is a summary of practice, not a contract; the incident notification policy has the detail.

Live status →Trust Centercontact@wrxstack.com
01 / What actually happens

The team fixes it.

There is no rotation to page and no bridge call to open. When wrxstack breaks, the team notices it or is told about it, works out what is wrong, and works on a fix. That is the whole process, described honestly.

How we find out
Someone notices, or you tell us. Either the site's own checks or a message from you. There is no 24/7 monitoring desk. If you see something broken, email contact@wrxstack.com and it goes to the team that works on it.
Who responds
The same team that builds it. There is no separate security department and no on-call lead to escalate to, because wrxstack is a small team. The people who build the product triage it and work it directly.
The fix
Understand it, then fix it. We aim to find the cause, ship a fix, and check that it held. No paging tiers, no war room, just the work.
Telling you
Directly, where it matters. Where the law requires us to tell you about a breach of your personal data, we tell you directly, usually by email. For other incidents, we may tell affected users directly or post on the status page, at our discretion.
02 / How the team triages

What gets dealt with first.

These are not paging tiers or response targets. They are how the team decides what to work on first when more than one thing is wrong. They describe an order of priority, not response times.

First

Data or security

Anyone's data exposed, altered, or at risk, or a confirmed security problem. This comes first, and it is where the legal notice rules below may apply.

Worked on first
Next

Site or product down

Atlas, Folio (the portfolio and personal-site builder), or the site is unavailable or badly degraded for people trying to use it. Worked on next, once any data or security issue is contained.

Worked on next
After

Something is off

A feature is misbehaving but the product still works and no data is at risk. Worked on in order, after the two above.

Worked on in turn
Logged

Minor or cosmetic

Small glitches, wording, and rough edges. Written down and handled as part of ordinary work, not as an incident.

Handled as normal work
03 / The one obligation

The one real deadline.

Most of this page describes how we work, and none of it is a contract. This part is different, because the law sets it. If personal data is breached, we follow the deadlines the law sets. We do not sign a BAA, so HIPAA breach rules do not apply to wrxstack.

GDPR Article 33
The supervisory authority, within 72 hours where feasible. Where we are the controller and a personal data breach is likely to result in a risk to people, we notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, as Article 33 requires. Where the law allows, a first notice can be followed by more detail later.
GDPR Article 34
Affected people, without undue delay, where the risk is high. Where the law requires us to tell you, we tell you directly, usually by email, with the information the law requires. Other laws, such as US state breach laws, may set their own rules, and we follow those that apply to us.
What we do not claim
No BAA, no HIPAA clock. We do not sign a business associate agreement and do not accept protected health information. Do not put it in wrxstack.
04 / After an incident

We work out what happened.

There are no past incidents to link to here, and we are not going to pad the page with drills to make it look lived-in. This is how we intend to approach the first real one.

A summary
Where useful and safe. We may publish a summary with the root cause and the change we made, where we think it is useful and it does not put users or the service at risk. Whether and what to publish is our decision.
Honest root cause
The actual cause. We aim to identify the change and the system that let it happen, not just "an issue occurred." The target is the thing that allowed the incident, not a person.
Ends in a change
Aimed at a change. We aim to make a code change, or a change to how the work is done, so the same thing is less likely to recur.
Live status
Checked from your browser. The status page checks the site, Atlas, and Folio in real time and reports what it observes right now. It does not store history and it does not estimate.
Trust Center · Incident response

See something broken?
Tell a human.

If you found a vulnerability, the responsible-disclosure path is below. For anything else that looks wrong, email the team that works on it.

Responsible disclosure →security@wrxstack.comBack to Trust CenterNo on-call rotation · no incident history · one small team