Prove TDI treats security as an operating requirement rather than a certification claim. Controls are designed to protect customer and organisational boundaries, preserve the integrity of evidence and decision records, and restrict material authority to authorised actors. Public statements are deliberately limited to controls and commitments that can be supported for the relevant environment and customer scope.
Security governance
Security decisions are expected to follow a risk-based, least-privilege and fail-closed approach. Material security conditions are not silently waived to accelerate releases or customer activation. Where a requirement depends on a specific production configuration, contract or deployment scope, that dependency must be validated before it is represented as available.
- Organisation and tenant boundaries are treated as security controls, not interface conventions.
- Material authority changes and protected actions remain explicitly controlled.
- Security, privacy and data-handling conditions are validated proportionately for live customer activation.
- Security exceptions and unresolved assurance conditions should remain visible until resolved or formally accepted by accountable authority.
- Audit and evidence-integrity controls must not be weakened solely to accelerate delivery.
Identity, access and authority
Access is designed around organisational context and the authority required for a user's role. Authentication alone does not create authority to view, alter or approve material decision information.
- Tenant-aware access boundaries restrict access to the relevant organisational context.
- Protected actions are subject to explicit authorisation rather than relying on interface visibility.
- Least privilege is the operating principle for roles, elevated access and service authority.
- Decision ownership, evidence contribution and approval authority remain distinct where separation of duties is material.
- Enterprise identity requirements such as SSO or additional authentication controls are confirmed against the proposed production scope rather than assumed from a generic platform claim.
Application and delivery security
Prove TDI's delivery model is designed to keep security-sensitive changes governed across development and release activity. Security-relevant behaviour should be reviewed in the context of the environment in which it will operate, including permissions, data access, integrations and deployment configuration.
- Development and production authority are treated as separate operational concerns.
- Code, configuration and deployment changes must not bypass material access-control or data-boundary requirements.
- Secrets and privileged credentials should not be exposed through public application behaviour or client-side assumptions.
- Dependencies and externally supplied services form part of the security scope and are assessed proportionately to their role.
- Security defects affecting material authority, confidentiality or integrity take precedence over cosmetic release objectives.
Data protection and information handling
Security and privacy are related but distinct. Prove TDI applies data-minimisation and purpose-aware handling principles to the decision context it processes. Customer-specific requirements for retention, deletion, subprocessors, transfer mechanisms or data location are confirmed through the applicable production and contractual scope before activation.
- Customer and organisational data boundaries are not inferred from naming conventions alone.
- Access to decision context should be limited to what is required for the authorised purpose.
- Evidence provenance is preserved so that security or governance review does not depend on an unexplained derived score.
- Personal-data handling is governed alongside the public Privacy Notice and applicable contractual terms.
- Scope-specific privacy, retention and subprocessor requirements are treated as explicit assurance conditions where material.
Logging, auditability and integrity
The platform is designed so material actions and evidence state can be assessed in context. Auditability is a control objective: it supports investigation, accountability, governed approval and the ability to distinguish current state from prior decision history.
- Material authority and decision actions should remain attributable to the relevant actor or system context.
- Evidence integrity and provenance must not be silently rewritten to improve a later result.
- Historical decision state should remain distinguishable from subsequent evidence or configuration changes.
- Security-significant events are handled according to their materiality and available operational context.
Incident handling and resilience
Suspected security incidents are expected to be assessed, contained, investigated and remediated proportionately to their impact. Customer notification, regulatory obligations, recovery objectives and service commitments depend on the nature of the event and the applicable contractual or legal scope; Prove TDI does not publish generic guarantees where those guarantees have not been established for the relevant service tier.
- Material confidentiality, integrity and availability events are treated as security incidents rather than ordinary product defects.
- Containment and preservation of trustworthy records take priority when an incident could affect evidence or decision integrity.
- Recovery and continuity requirements for enterprise use are confirmed in the applicable service and contracting scope.
Public assurance status
Prove TDI uses explicit status language so that a roadmap item, an operational control and an independently certified control are not presented as equivalent.
- Tenant-aware access and organisational boundaries: implemented as platform security principles and controls.
- Controlled authority and auditability: implemented as core platform and decision-governance principles.
- Customer-specific security, privacy, retention and subprocessor requirements: validate for the proposed production scope.
- Enterprise identity, service-level and recovery commitments: confirm for the proposed configuration and signed terms.
- ISO/IEC 27001 certification: not currently claimed.
- SOC 2 Type I or Type II attestation: not currently claimed.
How to interpret our security statements
“Designed for”, “aligned with”, “readiness” and “roadmap” do not mean certified, independently attested or legally compliant by default. Where independent assurance is not held, Prove TDI says so. Where a control is customer-, region- or configuration-specific, it is validated for that scope instead of being represented as universal.
Responsible security reporting
If you believe you have identified a vulnerability or security concern affecting Prove TDI, report it to security@provetdi.com. Please include enough information to reproduce or assess the issue and avoid accessing, changing or retaining data that you are not authorised to handle.
Enterprise security review
Organisations with procurement, public-sector, regulated-industry or enterprise assurance requirements can contact Prove TDI for a scope-specific review. The review should establish which controls are implemented, which depend on configuration or contract, which remain on the assurance roadmap and which independent certifications are not currently held.