Security.

Secure-development approach

Security is treated as part of architecture and engineering rather than as a separate compliance activity. We design systems around threat models, constrain access to least privilege, validate input at trust boundaries, and review code and configuration changes before deployment.

Dependencies are tracked and updated routinely. Static analysis, dependency auditing and automated tests run as part of continuous integration. Infrastructure is provisioned through code and deployed into isolated environments with role-based access.

Vulnerability disclosure

If you believe you have found a security vulnerability in a Pius-operated system, please report it responsibly.

• Email security@pius.tech with a description of the vulnerability, affected system, steps to reproduce and any supporting evidence.
• Allow reasonable time for investigation and remediation before public disclosure.
• Do not access, modify or delete data belonging to other users or clients.

We will acknowledge receipt, investigate promptly and keep you informed of progress. We do not pursue legal action against researchers who act in good faith and follow this process.

A machine-readable disclosure policy is published at /.well-known/security.txt.

Prioritisation and evidence

Security findings are assessed by severity, exploitability and business impact. Actively exploitable vulnerabilities in production systems are treated as urgent. Findings are documented with reproduction steps and verified against source code, configuration or runtime behaviour before being closed.

Dependency and supply-chain management

Application and infrastructure dependencies are declared in lock files and reviewed before adoption. Automated tooling flags known vulnerabilities in production dependency trees. Build pipelines run in controlled environments and publish reproducible artefacts.

Access and subcontractor controls

Access to client systems, source code and data follows least-privilege principles. Credentials are managed through secrets managers, rotated regularly and never stored in source control. Where subcontractors contribute to an engagement, they operate under the same access restrictions, confidentiality obligations and security expectations.

Incident and recovery readiness

Systems are designed with recovery in mind: automated backups, documented restoration procedures and tested failover. Logging and alerting support rapid detection and investigation. Incident response ownership is documented before incidents occur, not improvised during them.

AI tools and client data

We use AI-assisted tooling to improve engineering coverage and speed, including code review, test generation, architectural analysis and the triage of complex findings. AI output is treated as untrusted analysis. Material decisions and security findings are reviewed by senior engineers and verified against source code, configuration or reproducible tests.

Client code and sensitive information are handled within agreed data-processing and tooling boundaries. We do not train models on client data or share it with third-party AI services without explicit agreement.

Standards and frameworks

Our work is informed by established security guidance including OWASP, the NCSC's secure development and deployment principles, and relevant regulatory frameworks such as GDPR, the Cyber Resilience Act and DORA where they apply to client engagements. We pursue recognised certifications where they are commercially appropriate and will display them with their validity dates once obtained.

Contact

For security matters, contact security@pius.tech.

For general enquiries, see the contact page.