Security
These are KWAYZER’s security controls as the product records them — the same record a workspace’s Security settings read. Of 10 controls, 6 are built, 4 partly built and 0 not built. Where a control is not built, the line says what would have to exist.
These are counts, not a score. The controls are not comparable to one another — an unfilled DPA field and an absent incident register are not two of the same thing — and a control that RECORDS a policy is marked apart from one that ENFORCES it, because a policy nothing acts on is a sentence rather than a control.
Built
Service accounts and API keys
Enforced by the product.
SSO and SCIM provisioning
Enforced by the product.
Session visibility, revocation and limits
Enforced by the product.
Encryption in transit
Enforced by the product.
Audit trail and export
Enforced by the product.
Retention schedule
Enforced by the product.
Partly built
Deletion and data export SHUT
Erasure is switched off until the founder's pre-launch decision; the data export works.
Still needs: the founder's pre-launch decision to switch it on (until then nothing purges); before that, every workspace classified — 881 production workspaces are unclassified, and nothing classifies a new one at signup, so a test workspace could otherwise pass as a customer's; and an intake for a single person's deletion request rather than a whole workspace's.
Incident response
Recorded as a policy; nothing yet acts on it.
Still needs: the owners' notice sent from the product by email (it is composed from the record today and sent by hand); the 24-hour clock is shown, not enforced.
Attestations and certifications
Recorded as a policy; nothing yet acts on it.
Still needs: an actual third-party attestation. No SOC 2 or ISO 27001 audit has been performed, and the honest answer to a security questionnaire is that the controls exist and nobody external has tested them.
Data processing agreement
Recorded as a policy; nothing yet acts on it.
Still needs: the legal entity, address, contact and governing-law jurisdiction — a founder act, not an engineering one.
Incident policy
The founder of KWAYZER decides whether something is a security incident, how severe it is, and when it is resolved. There is no on-call rota; this is one person, stated plainly.
S1 — customer data at risk, or the product is down
Investigated immediately. The affected workspaces are told within 24 hours of the incident being confirmed, whether or not it is fixed by then.
S2 — a feature is broken or a figure is wrong for some customers
Fixed in the current run of work. Customers are told in the next release note.
S3 — degraded or cosmetic
Recorded, and fixed in the queue.
By email to the owners of the affected workspaces, and — for S1 — on this page's incident list. An incident is never removed from the list; it is marked resolved, with the date.
A notice says what happened, what data was involved, what has been done, and what the customer should do. It never states a figure that was not measured, and never says no data was affected unless a read proved it.
Incidents
No S1 incident has been recorded.