No implied authority
An application does not appoint Trace as a processor, approve access or start case work.
Security posture · Product truth
Trust starts with the claims we refuse to make.
Trace may need to coordinate highly sensitive request evidence. That demands a narrow processing boundary, explicit human authority and verifiable controls. This page separates current public truth from production requirements; it is not a certification statement.
The public boundary
Apply with context. Keep credentials and request data out.
The public website is for qualification. Do not paste connector secrets, identity documents, exports or the substance of a real person’s request into a public form.
Written scope first
Systems, data classes, purpose, access, reviewers, retention, deletion and delivery must be agreed.
Capacity must be real
Trace should only accept and charge for a pilot it can deliver under the described security and review boundary.
No SOC 2, ISO 27001, penetration-test, EU-only hosting, zero-knowledge, local-AI or “no subprocessors” claim is made.Those statements require evidence that has not been published.
Product-truth matrix
A control is not live because it appears on a roadmap.
The matrix records the allowed statement today and the evidence needed before Trace should make a stronger claim.
Scroll horizontally to view every control column.
| Area | Current status | Allowed wording | Evidence before stronger claim |
|---|---|---|---|
| Access minimisation | Design requirement | Prefer customer-produced exports or narrowly scoped, revocable access. No live self-serve connector claim. | Approved access matrix and revocation test |
| Encryption in transit | Production requirement | Customer data must use an agreed encrypted transfer path; the public form is not that path. | Architecture evidence and transport configuration |
| Encryption at rest | Production requirement | Required for any accepted pilot environment that stores customer case data. No algorithm or key-management claim is published yet. | Storage, key-management and recovery evidence |
| Tenant separation | Architecture requirement | Case data must be separated between customers. The implemented isolation model has not been publicly evidenced. | Architecture review and isolation test |
| Secrets management | Architecture requirement | Credentials must not enter public forms or ordinary case notes and must be revocable. Tooling is not publicly specified. | Secrets lifecycle and access logs |
| Role-based access | Planned control | Case preparers, authorised reviewers and customer users should have distinct permissions. No generally available RBAC claim. | Permission matrix and authorisation tests |
| Audit logging | Prototype pattern | Trace demonstrates timestamped case events. It does not claim a tamper-proof or cryptographically chained audit log. | Event schema, retention and integrity tests |
| Retention and deletion | Policy required | Case-specific retention and deletion must be agreed before processing. No universal retention schedule is published. | Approved schedule and deletion verification |
| Secure delivery | Operating requirement | Response packs should use an agreed delivery channel, not routine email attachment. No single delivery mechanism is promised. | Delivery design and access-expiry test |
| Incident response | Policy required | A reviewed incident process and notification path are required before production processing. No maturity claim is made. | Approved plan, roles and exercise record |
| Subprocessor governance | Disclosure required | Applicable subprocessors must be disclosed and contractually reviewed before an accepted processing scope. | Published list, agreements and change process |
| Vulnerability handling | Process required | A formal reporting and triage process is not yet published. General enquiries currently go to the contact address below. | Disclosure policy, security mailbox and triage SLA |
Intended data path
Customer-controlled at every boundary.
This is the operating requirement for an accepted pilot, not evidence that a production platform already implements every control.
Authorise
Name the purpose, systems, data classes, retrieval method, people and end date before access exists.
Required agreementMinimise
Prefer controlled exports or the narrowest feasible read path. Broad administrative access is not a default.
Design principleSeparate
Keep customer cases and permissions isolated, and prevent source credentials from becoming ordinary case content.
Architecture requirementReview
Put disclosure, erasure, exception and retention decisions behind an authorised human boundary.
Operating requirementDeliver
Use an agreed channel with appropriate access control and expiry rather than routine email attachments.
Mechanism to be agreedRevoke and delete
Remove source access and case data according to the accepted retention and deletion instructions, with evidence.
Policy requiredHuman control
Preparation can be delegated. Authority cannot be assumed.
Trace is designed to assemble evidence and expose uncertainty. The customer identifies the person with authority to approve the final action.
- Identity state is recorded; sufficiency remains a case-specific decision.
- Third-party information is flagged; disclosure or redaction is decided by an authorised reviewer.
- Retention conflicts are surfaced; erasure is not triggered autonomously.
- Draft wording is prepared; final communication remains under customer authority.
Prototype control pattern
Trace preparesDraft response assembled
Two open decisions carried into the review queue.
Authorised human boundary
Customer decidesDisclosure and erasure pending
No action runs before an authorised decision is recorded.
Trust centre backlog
Documents still need owners, review and evidence.
Placeholders are shown so a buyer can see what is missing. They are not empty links dressed up as completed assurance.
Not published
Data processing agreement
Legal review, controller/processor scope and approved execution process
Not published
Subprocessor list
Verified vendors, purposes, locations, safeguards and update process
Not published
Retention schedule
Case categories, default periods, customer controls and deletion evidence
Not published
Architecture summary
Reviewed data flow, boundaries, isolation and recovery design
Interim only
Security contact
General contact: hello@usetrace.eu. A dedicated security channel is still required.
Not published
Vulnerability disclosure
Safe-harbour wording, supported reporting channel and response workflow
Not published
Incident response summary
Roles, escalation, customer notification and exercise cadence
None claimed
Assurance reports
Independent assessment only after controls exist and evidence supports it
Interim security contacthello@usetrace.eu
Start a security conversation Use this for pre-contract security questions. Do not email vulnerabilities, credentials or personal request data until a supported secure channel is confirmed.
A controlled first request
Security review should happen before access, not after the first export.
Share the controls your organisation needs. Trace will only propose an accepted pilot where scope, data handling and operational responsibility can be made explicit.