Security and Vulnerability Disclosure

1. How the platform protects data

• Tenant isolation: every query runs under a restricted database role with row-level security, so one Institution's data cannot be read from another's — even if the application has a bug.
• Least privilege: capabilities are granted per role; reviewers are read-only by construction; watching session recordings needs its own permission.
• Authentication: managed sign-in with long passwords (15+ characters), breached-password checks, email verification, verification of new devices, and bot protection at sign-up.
• Encryption: TLS in transit; encryption at rest by our database and storage providers; data stored in the EU (Frankfurt).
• Session recordings mask typed inputs and passwords in the browser, and never capture cookies, headers or request bodies.
• Audit trail: administrative actions — invitations, role changes, removals — are logged.

Technical and organisational measures are set out in Annex II of the Data Processing Agreement.

2. Reporting a vulnerability

Email security@itspracticing.com with a description, the steps to reproduce, the affected URL or component, and the impact you believe it has. Our contact details are also published at /.well-known/security.txt. We will acknowledge your report within 3 business days, keep you informed, and tell you when it is fixed.

3. Rules for good-faith research

• Test only with accounts you own or have permission to use. Do not access, change or delete other people's data; if you reach it by accident, stop, do not keep it, and tell us.
• Do not degrade the service: no denial-of-service, load testing, spam or social engineering of our staff, Institutions or users.
• Do not test our providers' infrastructure (hosting, database, authentication) — report issues in their services to them.
• Give us reasonable time to fix the issue before disclosing it publicly; we aim to fix critical issues within 30 days and will agree a disclosure date with you.

If you follow these rules, we consider your research authorised, will not pursue legal action against you for it, and will ask others not to either. We do not currently run a paid bug bounty, but we are glad to credit you.

4. Usually out of scope

• Findings from automated scanners without a demonstrated impact.
• Missing security headers or cookie flags without a practical exploit.
• Behaviour inside a simulation that is part of the fictional scenario (for example, a fictional system being insecure on purpose in a cybersecurity mission).
• Rate limiting on non-sensitive endpoints, clickjacking on pages without sensitive actions, and self-XSS.