STR3.AI
Security and Data Handling
Brief for IT, security and compliance reviewers.
Version 1.2 · Sep. 03, 2026 · Prepared by STR3
This brief describes how a nunNEO diagnostic handles the information a subject organization provides, what controls sit between that information and anything that leaves the estate and what is settled as a matter of recorded policy rather than practice.
1. What the diagnostic is
A nunNEO diagnostic is a staged analysis that takes a structured intake from the subject organization, researches public evidence about it, produces a written assessment and delivers that assessment as a report. It runs as software. It is not a consulting engagement with a shared workspace, and no part of the subject's material is circulated to an analyst pool.
2. Client data and model training
Client data is never used to train models. This is a ratified position in the decision record, not a practice statement and not an aspiration.
Aggregate analytics derived from the archive of past diagnostics run on an anonymized basis with minimum-count suppression, and they stay internal. They calibrate the instrument. They are not an outbound product, and archive derived positioning does not appear in any report, partner package or published material.
The separation between a client's material and the internal analytics layer is re-tested on a standing six-week cycle. It is a recurring control with a named accountable owner, not a one-time attestation.
3. How a diagnostic is executed and recorded
Every diagnostic runs as a durable, staged workflow. Each stage is a separate step whose inputs, outputs, token usage, cost and latency are recorded as its own ledger row.
The record of execution is the database, not the document. A report can be reconstructed from its stored stage outputs. Each run states the exact model configuration it used, logged before any generation begins.
4. Nothing ships unchecked
A compliance pass runs over the finished text before delivery. Findings are classified. Those with a deterministic, provable repair are repaired at render time. Those without it hold the report, and the report is not sent.
Holding is the default rather than the exception. The same gate is shared by the normal delivery path and by every internal path that can produce a report, so there is no route that skips it.
When a held report is released, that release is an explicit recorded act with an operator and a timestamp. It is never a silent send.
5. Consent precedence
If a respondent declines to have two diagnostics cross-referenced, that decision is honored even when they have separately supplied the identifier that would enable it. No wins, always.
Contradictory signals are never resolved silently in the system's favor. The contradiction is logged, the link is blocked and the respondent is asked to choose.
An unanswered question is treated differently from a declined one. Silence is not consent, and it is not refusal either.
6. Access, retention and revocation
Report access is gated by a per-report token that carries an expiry and can be revoked. A revocable token was chosen over a signed URL precisely because it can be withdrawn for a single report without affecting any other.
Report artifacts carry a defined share window of 30 days.
Material marked as confidential deliverable content is registered as not-for-public-surface, and a lint enforces that registration over the source rather than leaving it to review.
7. Audit trail
Delivery, release and every outbound write to a connected system are individually recorded with an outcome and a timestamp.
A report's history, from intake through render, compliance check, hold or delivery and any subsequent release, is reconstructable from those records.
8. Model layer and processing
The model layer is a single vendor by architectural decision rather than by default, and that decision is recorded with its rationale. Model identifiers do not appear on any client-facing surface.
A model-version change is treated as an instrument change. It opens a new measurement epoch, and outcome comparisons are only valid within a single epoch. A version is not swapped underneath a client's results.
Two providers process subject material in the course of producing a diagnostic:
-
Cloudflare: edge compute, application hosting and storage
-
Anthropic: the model layer
Delivering the result and keeping the record involves a further set, each scoped to its own purpose:
-
Resend: report delivery and notification email
-
HubSpot: customer relationship records
-
Notion: internal record keeping
-
Google Workspace: business correspondence and document storage
Subject material is processed by our model provider, Anthropic, under its standard commercial terms: inputs and outputs are deleted from its systems within 30 days in the ordinary course, are never used to train models, and may be held longer only where content is flagged for usage-policy review or where the law requires.
No processor outside this list receives subject material. Adding one is a recorded decision, and this brief is updated when it happens.
9. How findings are verified
Findings are checked by a pass whose instruction is to refute them rather than to confirm them, and which defaults to refuted under uncertainty.
Scores, bands and exposure figures are computed arithmetically. They are not written by a language model. The narrative explains a number. It never produces one.
Closure of a release is not accepted on a self-report. The most recent closure review found defects that the authoring pass had verified as clean, which is the reason an independent adversarial review is now a standing requirement rather than a discretionary one.
10. Standards posture
STR3 holds no third-party security or AI certification. There is no SOC 2 report, no ISO/IEC 27001 certificate and no ISO/IEC 42001 certificate, and no external audit has been performed. Stating otherwise would breach the principle this brief closes on.
That is a decision rather than an oversight. External certification, penetration testing and formal verification are deferred by recorded decision at the current stage, and the decision is revisited when a client's procurement requires it. STR3 will say so at that point rather than claim a readiness it does not have.
The controls described above were designed with reference to three published frameworks. ISO/IEC 42001, the management system standard for artificial intelligence, informs the governance, data handling and human oversight sections. ISO/IEC 27001 informs access control, logging and supplier management. The European Commission's Ethics Guidelines for Trustworthy AI inform the requirements on human oversight, technical robustness, data governance, transparency and accountability that sections 2 through 9 describe. A control to requirement mapping is available to reviewers on request.
STR3 assesses a nunNEO diagnostic as a business analysis tool that falls outside the high-risk categories the EU AI Act sets out in Annex III. Where a person interacts with the intake agent, that person is told before the conversation begins that they are interacting with an AI system.
What stands in place of a certificate is a maintained record. Every control in this brief is enforced in code or in a recorded decision, not in a policy document that describes an intention. This brief carries a version and a date, it is reviewed every six months and whenever a control changes, and each revision states what changed. Version 1.1 corrected two claims in version 1.0 that this brief's own standard would not accept. Version 1.2 added the model-provider retention statement in section 8.
Questions this brief invites
Reviewers who need a control not described here should ask. The controls above are the ones that are settled and recorded. Where something is not yet settled, STR3 will say so rather than describe an intention as a control.
Questions on this brief: nunneo@str3.com Privacy questions: privacy@str3.com
© 2026 STR3. All rights reserved.