← Ataski ·
Trust & security ·
DPA ·
Subprocessors
This is the canonical English version. Native translations for DE / ES / FR / PT / RU are pending counsel sign-off.
Approved 2026-10-08
Risk Management Policy
Owner: the founder. Approved: 2026-10-08. Review: annually, and on
any significant change. The register itself is re-read more often (§4).
Scope: risks to the confidentiality, integrity and availability of Customer
Data, and to Ataski's ability to deliver the service — including vendor,
legal and AI-output risk. The risks themselves are listed in
docs/security/risk-register.md; this page is the method.
1. Identify
A risk enters the register from any of these, on the day it is noticed:
- an incident or a near miss, and its post-mortem;
- a self-assessment answer of "No" (the CSA CAIQ,
docs/security/soc2-readiness.md);
- a new vendor, or an ADR that changes the architecture;
- a finding under
vulnerability-management.md that cannot be fixed in time;
- a customer security questionnaire that asks about something we do not do;
- a vendor notice (an outage, a breach, a change of terms).
2. Assess
Two three-point scales, multiplied.
|
1 — Low |
2 — Medium |
3 — High |
| Likelihood |
not expected within a year |
plausible within a year |
expected within a year, or it has already happened to us |
| Impact |
inconvenience; no Customer Data affected; degraded under a day |
one customer affected, recoverable; or an outage of up to a day |
Customer Data exposed, lost or wrongly sent; several customers down for more than a day; a breach notification |
Score 6–9 is high, 3–4 medium, 1–2 low. The score is a judgement,
written down so the next review can disagree with it.
3. Treat
Every risk gets an owner, a treatment and a next step:
- Mitigate — a control that lowers likelihood or impact, with a target date.
- Accept — a written decision with its reason. Acceptance is not permanent:
every accepted high risk is re-decided at each review. Where accepting a risk
weakens a rule in another policy, the acceptance is an ADR
(
information-security.md §6).
- Transfer — to a vendor under contract (for example physical security to
the hosting providers). Insurance is not used today.
- Avoid — stop doing the thing.
The owner is the founder for every risk, because there is no one else. That is
itself the first risk in the register.
4. Review
- The register is re-read at the quarterly self-review
(
docs/security/evidence-checklist.md) and immediately after a SEV-1 or SEV-2
incident, a new sub-processor, an architectural ADR, or the first hire.
- This policy annually.
The register was first issued on 2026-10-08, together with this policy; there
is no earlier review history.
5. Appetite, in plain words
- None for cross-tenant exposure of Customer Data, for using Customer Data
outside the disclosed sub-processors, or for claiming a control that does not
exist.
- Availability before confidentiality: an outage is accepted to stop a leak
(the same order the incident plan contains incidents in).
- The concentration risk of a one-person company is accepted and disclosed,
not hidden.
6. Not in place today
- No independent review. No board, committee or adviser reviews the
register; it is self-assessed by the person who runs the system.
- No quantitative model. Scores are ordinal judgements, not money.
- No cyber-liability insurance.