Security Policy

1.1 AIPTx processes sensitive information: details of our customers' systems, the vulnerabilities found in them, and the evidence proving those vulnerabilities are exploitable. A compromise of our platform would be a compromise of our customers' security posture.

1.2 We design on that basis. Least privilege by default, encryption everywhere, segregation between customers, and the assumption that any component may be attacked.

1.3 This page describes the controls we operate. Customers with specific requirements should contact [email protected]; we complete security questionnaires and provide documentation under NDA.

1.4 AI/ML model security. Where we use AI or machine learning models, we apply appropriate security measures (including access controls, data segregation, encryption, monitoring and testing) to protect customer data and to mitigate risks such as prompt injection and data leakage. We do not use customer data to train machine learning models, whether our own or those of a third party.

The sentence above is deliberately identical to clause 3.4 of our Data Processing Agreement, clause 8.6 of our Privacy Policy and clause 8.5 of our Terms of Service. If it ever changes, it changes in all four.

2.1 At rest. Customer data, including assessment results, findings, evidence and stored credentials, is encrypted using AES-256. This covers databases, object storage and backups.

2.2 In transit. All connections use TLS 1.3, with HTTPS enforced across every endpoint. HTTP requests are redirected and HSTS is enabled.

2.3 Credentials you supply for authenticated testing are encrypted at rest, access-controlled, and used only to perform the testing you configure.

2.4 Key management. Encryption keys are managed separately from the data they protect, access to them is restricted to the systems and roles that require it, and they are rotated. The key management service, the rotation frequency and the separation of duties around key access are to be confirmed and recorded here. Enterprise reviewers ask for all three.

3.1 Hosting. The platform runs on a third-party cloud provider. Our provider maintains its own certifications, including SOC 2. Those certifications cover our provider's controls, not ours. AIPTx's own position on certification is set out in clause 9, and the two should not be read together. The named provider is to be confirmed and recorded here.

3.2 Data region. The regions in which customer data is hosted and processed are being confirmed, and will be listed here and in Annex I of our Data Processing Agreement once they are. Until that is settled this page does not assert a United Kingdom region. Where personal data subject to UK GDPR is transferred outside the United Kingdom, the transfer is made under the mechanisms set out in our Data Processing Agreement at clause 10; those mechanisms are operative rather than theoretical for as long as this clause reads this way.

The regions offered, and whether all customer data, backups and support data remain within the region selected, are to be confirmed. This clause, clause 10.1 of the Data Processing Agreement and clause 11.1 of the Privacy Policy record the same position and must be updated in a single change.

3.3 Physical security. Our hosting infrastructure is located in data centres protected by appropriate physical security measures, including controlled access, surveillance, environmental controls, and measures designed to prevent unauthorised physical access to systems and facilities.

3.4 Network protection. DDoS mitigation and a web application firewall protect the platform perimeter.

3.5 Segregation. Customer environments and data are logically separated with enforced boundaries. The mechanism (separate schemas, row-level security, per-tenant encryption keys) is to be confirmed and described here. Specificity on this point is worth real credibility with a multi-tenant audience.

3.6 Availability. We operate the web application to an availability target, measured monthly and excluding scheduled maintenance and events outside our reasonable control. It is a target rather than a guarantee; clause 9 of our Terms of Service governs the contractual position. The target figure, how it is measured, and the address of the status page carrying current and historical availability are to be confirmed and recorded here.

3.7 Backups. Backups are automated daily, retained for 30 days, encrypted and geographically distributed. Restoration procedures are tested. The frequency of restoration testing is to be confirmed and recorded here. A backup that has never been restored is a hypothesis.

4.1 Multi-factor authentication. MFA is required for all AIPTx personnel accessing production systems, and is offered to customers for their own accounts. Whether customer MFA is available or enforced, and on which plans, is to be confirmed and stated here; the distinction is the whole question in an enterprise review.

4.2 Least privilege. Role-based access control applies least privilege. Access to customer data is limited to personnel who require it to deliver the Services or provide support.

4.3 Password security. We enforce a password policy designed to prevent weak or compromised credentials, including appropriate length and complexity requirements, protection against commonly used or previously compromised passwords, and secure storage using industry-standard cryptographic hashing.

4.4 Logging and monitoring. Access to production systems and to customer data is logged and monitored. Security alerts and anomalous activity are investigated in accordance with our security procedures. The monitoring and SIEM tooling, the log retention period, and whether alert triage genuinely runs around the clock are to be confirmed and recorded here. An earlier version of this page claimed monitoring 24 hours a day; it is stated again only once it describes a rota rather than a tool.

4.5 Access reviews. Access to production systems and customer data is reviewed on a defined schedule, and is revoked on the same day an individual leaves. The review frequency is to be confirmed and recorded here.

4.6 Customer access control. Role-based access applies within your workspace, with reports scoped to the projects a user is assigned to.

5.1 Security is part of our development lifecycle rather than a stage at the end.

5.2 Code review is required before merge. Static analysis (SAST) and dependency scanning run in our pipeline, and dynamic testing (DAST) runs against pre-production environments.

5.3 We test our own platform with our own product. Findings are triaged and remediated through the same process we recommend to customers: see clause 8.

5.4 Dependency and vulnerability remediation. Dependencies are monitored for known vulnerabilities and updated on a defined schedule, with expedited handling for critical issues. Security vulnerabilities are assessed and remediated within timeframes appropriate to their severity and risk, taking into account the requirements of Article 32 of the UK GDPR concerning the appropriate level of security and the ability to restore the availability of and access to personal data in a timely manner.

Target remediation windows by severity are to be confirmed and published here. Enterprise reviews ask for them, and a published window is stronger than a general statement, but only once it is one the engineering team has agreed it can meet.

6.1 Background screening is conducted for personnel with access to production systems. The scope of screening is to be confirmed and recorded here.

6.2 All personnel are bound by confidentiality obligations.

6.3 Security and data protection training is provided at induction and repeated thereafter. The frequency of refresher training is to be confirmed and recorded here.

6.4 Access is provisioned on a least-privilege basis and removed promptly on departure.

7.1 We maintain a documented incident response plan covering detection, triage, containment, eradication, recovery and post-incident review.

7.2 Customer notification. Where an incident affects customer data, we notify affected customers without undue delay and within 72 hours of becoming aware, in accordance with our Data Processing Agreement.

7.3 Regulatory and individual notification. Where AIPTx acts as processor, the customer, as controller, is responsible for assessing whether notification to the ICO is required under Article 33 of the UK GDPR and whether notification to affected individuals is required under Article 34. We will provide the customer with the information and reasonable assistance necessary to make those assessments and to comply with its notification obligations.

Where AIPTx acts as controller, we will notify the ICO without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach where notification is required under Article 33 of the UK GDPR. Where the breach is likely to result in a high risk to the rights and freedoms of affected individuals, we will also notify those individuals without undue delay in accordance with Article 34.

7.4 Incident response procedures are tested. The frequency of testing is to be confirmed and recorded here.

7.5 To report a suspected security incident affecting your account, contact [email protected] immediately.

8.1 We are a penetration testing company. It would be a poor advertisement if our own platform were untested.

8.2 Independent testing. Penetration testing of the platform is conducted by an independent third-party firm. Who performs the testing, how often, and whether a summary letter is available to customers under NDA are to be confirmed and recorded here.

8.3 Continuous internal testing. Our own platform is assessed using AIPTx on an ongoing basis, including authenticated multi-role testing of tenant isolation.

8.4 Vulnerability disclosure. We operate a disclosure policy for external researchers. It is set out in full at clause 10 of this page.

9.1 SOC 2 Type II. This page makes no SOC 2 representation. A SOC 2 statement is only meaningful with the certifying body, the audit period, the trust services criteria in scope and the availability of the report attached to it, and a reviewer will ask for all four. Until they are recorded here, nothing on this page should be read as a claim that AIPTx holds a SOC 2 Type II report.

9.2 ISO/IEC 27001. This page makes no ISO/IEC 27001 representation. A certification claim is only meaningful with the certifying body, the certificate number, the validity period and the scope statement of the certified information security management system attached to it; scope in particular, because a certificate can be narrow. Until they are recorded here, nothing on this page should be read as a claim that AIPTx holds an ISO/IEC 27001 certificate.

Both statements above are written to be replaced. Fill in the certifying body, certificate number, audit period and scope from the certificates themselves, or leave the clauses as they stand. A certification claim from a security vendor is checked first and it is checked by people who know how.

9.3 Clauses 9.1 and 9.2 relate to AIPTx's own information security management. They are distinct from our hosting provider's certifications referred to in clause 3.1: a provider's certification covers the provider's controls and says nothing about ours.

9.4 Supporting our customers' compliance. Assessment findings map to PCI DSS, SOC 2, ISO 27001, HIPAA, GDPR, NIST and CIS controls, with gap analysis in reports. This supports a compliance programme; it does not constitute compliance, and it is not a statement that AIPTx is certified or assessed against any of those frameworks.

9.5 Data protection. We comply with the UK GDPR, the Data Protection Act 2018 and, where applicable, the EU GDPR. See our Privacy Policy and Data Processing Agreement.

10.1 We welcome reports from security researchers and we will not take legal action against anyone acting in good faith within this policy. This clause is that policy in full; a standalone page for researchers is planned but is not published yet, so nothing here depends on it.

10.2 How to report. Send reports to [email protected]. A published PGP key for encrypted reports is to be confirmed and linked here. Until it is, tell us in plain text that you hold something sensitive and we will arrange a secure channel before you send details.

10.3 In scope. Our production web properties and public APIs, and the AIPTx client tooling.

The definitive list of in-scope hosts and assets is to be confirmed and published here. Until it is, if you are unsure whether something is in scope, ask at [email protected] before you test it; we would rather answer that question than receive a report we have to decline.

10.4 Out of scope. The following are outside this policy:

• customer environments and any system belonging to a customer;
• third-party services we use;
• social engineering of our staff;
• physical attacks;
• denial-of-service testing; and
• reports from automated scanners without demonstrated impact.

10.5 Safe harbour. Where you act in good faith, stay within scope, avoid privacy violations and service disruption, do not access or modify data beyond what is necessary to demonstrate the issue, and give us reasonable time to respond before disclosure, we will treat your research as authorised and will not pursue action under the Computer Misuse Act 1990 or equivalent legislation.

10.6 Our commitments. We will acknowledge your report, assess it, keep you updated while it is open, and tell you when it is fixed. The response targets attached to those stages are being set with the people who will answer the mail, and are published only once we are confident of meeting them; a missed public commitment to a researcher is worse than an unstated one.

10.7 Recognition. We will credit you for a valid report unless you prefer otherwise. A researcher acknowledgements page, and whether monetary rewards are offered and on what basis, are to be confirmed. Nothing on this page is an offer of payment for a report.

10.8 Coordinated disclosure. We ask that you give us a reasonable period to remediate before disclosing publicly, and we will work with you on timing where a fix takes longer. The specific period we ask for is to be confirmed and stated here.

11.1 A current list of the third parties that process customer data on our behalf, with the service provided and the processing location for each, is available on request from [email protected]. It is not yet published as a page on this site. When it is, this clause will link to it.

11.2 We give at least 30 days' notice before adding or replacing a sub-processor, and customers may object. See our Data Processing Agreement.

For questions about this policy, please contact:

• Security and vulnerability reports: [email protected]
• Data protection: [email protected]
• Legal: [email protected]

Registered office

• 167-169 Great Portland Street
• Fifth Floor
• London, W1W 5PF
• United Kingdom

Registered in England and Wales.