Last updated: 1 September 2026

Operator: People Building Ltd Company number: 06969239 Address: 15 Queensway, Hemel Hempstead, Hertfordshire, HP1 1LS, United Kingdom Email: info@peoplebuilding.co.uk ICO registration: Z2203181

1. Approach

People Building uses proportionate technical and organisational measures intended to protect Tupolis. No online service can guarantee absolute security, and detailed defensive configuration is not published where that would increase risk.

2. Security by design

New features should consider data minimisation, authentication, authorisation, storage/transmission, logging, misuse, third parties, deletion/retention and failure modes before release.

3. Infrastructure and transport

Tupolis uses cloud and network services appropriate to its operation, including AWS and Cloudflare where applicable. HTTPS and recognised secure transport should protect authenticated traffic.

4. Access control

Administrative/developer/support access should follow least privilege, use named accounts where practicable, and be removed when no longer required. Restricted practitioner functions require server-side/API authorisation, not merely hidden buttons.

5. Authentication

Passwords must not be deliberately stored in readable plain text. Password reset/session mechanisms must be protected. Higher-risk administrative access should receive stronger controls such as MFA where available/appropriate.

6. Practitioner uploads

Restricted upload functionality is for appropriate professional resources, not general client-record storage. File types, size, access and malicious-content risks should be controlled.

7. Development and secrets

Use controlled repositories and development access. Do not publish API keys, credentials, tokens or production secrets in source code. Avoid unnecessary use of live personal data in test/development systems.

8. AI-assisted development

Using AI coding tools does not authorise disclosure of live databases, children's/safeguarding information, client records, credentials or other unnecessary sensitive information.

9. Updates and vulnerabilities

Take a risk-based approach to patches, dependencies and identified vulnerabilities. Security concerns may justify temporarily disabling functionality.

10. Logging/error monitoring

Logs may support security, reliability and troubleshooting but should avoid passwords, tokens, payment-card information and unnecessary sensitive/client/safeguarding data. The actual production error-monitoring provider must be verified before being named publicly.

11. Backups and resilience

Backups may support disaster recovery and continuity and should be access-controlled/protected. Deleted information may remain temporarily until normal backup expiry.

12. Third parties

Significant providers should be reviewed for security, data-processing terms, access, processing locations/subprocessors and incident arrangements.

13. Future AI security

Before AI launches, review permission boundaries, user isolation, prompt injection, confidential-system extraction, data leakage, provider security, conversation retention and tool/action permissions. AI should have only the access it needs.

14. Children

Security design should recognise that children may disclose information, share devices/credentials or misunderstand warnings. Children should not be expected to compensate for unsafe design.

15. Incident response

People Building should be able to contain, investigate and remediate incidents, assess personal-data breach obligations, communicate where required and conduct post-incident review.

16. Reporting

Report suspected compromise, vulnerabilities or phishing to info@peoplebuilding.co.uk with subject Tupolis Security. Reporting a vulnerability does not authorise accessing other users' data, disruption or further intrusion.