Security and Trust Evidence

Security review starts with scope. This page separates implemented controls, independent assurance, contractual commitments, and work that is not publicly available. It does not turn a policy, a provider report, or a source file into a certification.

• Implemented control — a bounded control or public process is described with its limitations.
• Independent assurance — a third party has assessed the named entity and scope. No current Noxtica report is listed below.
• Contractual commitment — the obligation exists only when the cited agreement and scope apply.
• Planned / not available — public evidence is absent, incomplete, or not approved for publication.

Inventory reviewed: 2026-09-20. Next review due: 2026-12-20.

Evidence inventory

Each row names its evidence type, availability, owner, and review window. A link is shown only when a public destination exists. Every row was reviewed 2026-09-20 and is due for review by 2026-12-20.

Cryptography boundary

A protocol or signature name is not evidence that every payload is encrypted between end users. Review each layer against the exact service, data class, and endpoint.

1. Transport protection. Network transport protects data between configured endpoints. It does not describe how data is stored or whether application payloads remain encrypted between their origin and final recipient. Status: scope and endpoints require current service evidence.
2. Signatures and integrity. A digital signature can support integrity and signer authenticity for signed bytes. A signature does not encrypt the signed payload. Do not present signed tokens as encrypted tokens.
3. At-rest protection. Storage protection must be evaluated per service, data class, key boundary, and provider. No universal at-rest statement is approved in this inventory.
4. Payload end-to-end encryption. Current public evidence does not authorize a Noxtica end-to-end payload-protection claim. The safe public status is not available.

Module data scope

This summary is for evaluation, not legal advice. Confirm the enabled modules, configuration, contract, and current policy before deployment. Each module below is described across the same seven fields: inputs and sensitive-data possibility; trigger, configuration, and consent; client and server processing; storage and access; retention and deletion; external providers; and behavior when disabled or unavailable.

Browser risk collection

• Inputs: browser, device, network, request, and timing signals can be personal data or become identifying when combined.
• Trigger and consent: collection depends on customer integration and configuration. The customer must establish notice, lawful basis, and consent where required.
• Processing: the browser collects supported signals; server-side services can add request and network context for a risk lookup.
• Storage and access: depend on the customer workspace, credentials, enabled surfaces, and current product configuration.
• Retention: must be confirmed for the applicable data class and customer configuration; no universal period is stated here.
• External providers: current infrastructure and service providers are listed in the subprocessor register.
• When disabled or unavailable: integrations must handle a missing or unavailable result rather than infer low risk.

Session replay and behavioral evidence

• Inputs: recorded interactions, navigation, diagnostics, and session context can contain personal or sensitive content depending on the integrated page.
• Trigger and consent: replay starts only after tenant, domain, sampling, policy, legal-basis, DNT/GPC, and consent gates that apply to the deployment admit recording.
• Processing: a bounded early buffer remains in browser memory before admission; admitted replay payloads can then be sent for the replay workflow.
• Storage and access: recorded payload access requires an eligible session and an authorized role; browser risk collection is a separate module.
• Retention: follows the enabled replay configuration and applicable terms, not the browser-risk defaults.
• External providers: listed in the subprocessor register; the enabled deployment must be reviewed separately.
• When disabled or unavailable: denying or disabling replay discards the early replay buffer and does not disable separate browser-risk collection.

Account and session linking

• Inputs: a fingerprint identifier can be associated with a customer-controlled session, account reference, or transaction; that association can be personal data.
• Trigger and consent: the customer chooses whether to create the association in its server-side integration and remains responsible for the purpose and notice.
• Processing: the browser obtains an identifier; the customer backend can carry it into a server-side lookup or its own session record.
• Storage and access: customer systems control their account or session mapping. Noxtica access remains bounded by the credential and workspace used for lookup.
• Retention: the customer must align its mapping retention and deletion with the relevant Noxtica data class and its own records.
• External providers: follows the services used for browser collection and server-side lookup.
• When disabled or unavailable: without the customer-created association, Noxtica evidence is not linked to a customer account by this integration path.

Identity verification

• Inputs: no public, module-specific input inventory is currently approved for an identity-verification workflow.
• Trigger, consent, processing, storage, retention: not publicly represented.
• External providers: no identity-provider list is represented beyond the current general subprocessor register.
• When disabled or unavailable: treat the module as unavailable unless a separately reviewed product and privacy scope is supplied.

AI assistance and MCP

• Inputs: approved read surfaces can include policies, rules, domains, recent risk evidence, distributions, and audit information; those records can contain personal data.
• Trigger and consent: the operator assistant follows the signed-in operator context. External MCP access is separately enabled and requires a scoped token and tenant opt-in.
• Processing: these public paths are server-side, read-only access. They do not authorize configuration changes or traffic actions.
• Storage and access: existing workspace access and retention still apply. Token scope does not make the underlying records anonymous.
• Retention: follows each underlying record type; AI access does not create one universal retention rule.
• External providers: confirm the current model and infrastructure provider scope for the enabled deployment against the subprocessor register.
• When disabled or unavailable: no agent access is provided through that path; existing product data remains governed by its module.

Commercial, support, and walkthrough data

• Inputs: contact details, company information, selected interests, and voluntarily supplied message or preparation content are personal data.
• Trigger and consent: a visitor chooses to submit a contact, support, or walkthrough request. Marketing consent is separate where offered.
• Processing: the landing form sends submitted fields to the server-side contact workflow for the requested follow-up.
• Storage and access: authorized commercial or support operators can access accepted requests according to the active workflow and account controls.
• Retention: follows the current privacy policy, applicable terms, and a verified request process; no response-time promise is made here.
• External providers: current communications and infrastructure providers are listed in the subprocessor register.
• When disabled or unavailable: if the form or required service is unavailable, no successful receipt is represented and the visitor can use the published contact route.

Review routes

• Privacy policy — controller and processor roles, data categories, purposes, rights, retention, and contact routes.
• Subprocessors — the current public list of third-party service providers.
• System status — current service state and status history. This is not a contractual SLA.
• /.well-known/security.txt — the maintained vulnerability-reporting channel.
• Contact — request available procurement materials for the exact service and deployment under review.

Related reading

• Customer capability reference — governance and data-control capability family.
• Engineering principles — the operating constraints behind customer deployments.
• Backend integration — scoped server credentials and trusted lookups.
• FAQ — compliance, outage handling, and on-prem questions.