amber.systems security testing schedule

Version 2026-08-18 - last updated 18 August 2026

1. When this schedule applies

1.1 This Security Testing Schedule applies where an Order Form or Statement of Work incorporates it for penetration testing, vulnerability assessment, configuration review, adversary simulation, code review, social-engineering assessment, red teaming, security validation or related authorised testing (Security Testing).

1.2 This schedule forms part of the Contract together with the General Terms of Business. Capitalised terms not defined here have the meanings given in the General Terms.

1.3 Security Testing must not begin until the parties have agreed written Security Testing Rules of Engagement (ROE) identifying the scope and safety controls. The ROE take precedence for authority, targets, techniques, timing, stop conditions and evidence handling.

1.4 Our public security research and vulnerability disclosure policy governs independent good-faith research against amber.systems systems. It does not replace the customer-specific ROE for paid testing.

2. Customer authority

2.1 The Customer requests and authorises us to perform the Security Testing described in the ROE, including acts that would otherwise be unauthorised, to the extent of the Customer’s legal authority over the in-scope systems, accounts, data and facilities.

2.2 The Customer warrants that, before testing begins, it:

• owns or controls every in-scope target, or has obtained express written permission from each relevant owner or controller;
• has authority to permit the agreed techniques, access and processing;
• has obtained any approval required by a cloud, hosting, communications, software, platform or other third-party provider;
• has identified third-party, shared, safety-critical or regulated systems that could be affected; and
• has authority to instruct us regarding any personal data, communications, credentials or confidential information that may be encountered.

2.3 The Customer must provide evidence of authority on reasonable request. We may refuse or pause work where authority is unclear, incomplete or contradicted by a third party.

2.4 The Customer must not ask us to conceal testing from a system owner, provider or authority whose permission is required.

2.5 If an authority or third party investigates activity that was within the agreed ROE, the Customer will, where lawfully able, promptly and truthfully confirm in writing that it requested and authorised that activity. The Customer will provide us with reasonable cooperation needed to demonstrate the authorisation.

3. Rules of Engagement

3.1 The ROE should identify, as relevant:

• hostnames, IP ranges, applications, APIs, repositories, facilities, identities and other in-scope assets;
• expressly excluded assets and third-party dependencies;
• test dates, time windows and time zone;
• our source addresses, accounts, domains, telephone numbers or other test identifiers;
• permitted and prohibited techniques;
• production, staging and test-environment distinctions;
• permitted levels of exploitation, persistence, data access, denial-of-service, social engineering and physical testing;
• customer and amber.systems emergency contacts;
• stop conditions and incident procedures;
• handling of credentials, personal data and evidence;
• reporting, disclosure and retesting arrangements; and
• any relevant provider notifications or approvals.

3.2 An asset is not in scope merely because it is discoverable from, linked to, hosted with or technically connected to an in-scope asset.

3.3 A material expansion of target, technique, time window or access requires written approval through an updated ROE or Change Request.

4. Testing conduct and safety

4.1 We will perform Security Testing with reasonable care and skill and in a manner proportionate to the agreed objective and environment.

4.2 Unless expressly permitted by the ROE, we will not intentionally:

• cause material service degradation or denial of service;
• destroy, corrupt or irreversibly alter data;
• establish persistence beyond what is minimally necessary to demonstrate impact;
• move laterally beyond an in-scope boundary;
• send real malicious content to people outside an agreed simulation;
• exfiltrate bulk data;
• access third-party systems; or
• perform physical intrusion, phishing, vishing, smishing, credential stuffing or password spraying.

4.3 Where exploitation is permitted, we will use the least intrusive technique reasonably capable of validating the issue and will stop once sufficient evidence has been obtained.

4.4 A proof of impact may use synthetic, Customer-provided or controlled test data wherever reasonably practicable. Where production data is unavoidably encountered, section 7 applies.

4.5 We may decline a technique or stop work where we reasonably believe it creates an unacceptable risk to people, data, systems, third parties or our legal position.

5. Customer preparation and operational responsibility

5.1 Before testing, the Customer must:

• maintain current and tested backups suitable for the in-scope environment;
• identify fragile, safety-critical, legacy or high-availability systems;
• ensure appropriate monitoring and incident-response personnel are available;
• approve test accounts and access;
• coordinate internal teams and third parties that need to know about the test; and
• provide an emergency stop contact with authority to make operational decisions.

5.2 Testing can trigger alerts, lockouts, rate limits, failovers, provider abuse processes and other protective controls. The Customer is responsible for internal communication and any provider allow-listing or notification unless the ROE assigns that task to us.

5.3 We are not responsible for loss that results from a pre-existing defect, unsupported system, absent backup, hidden dependency or Customer instruction, except to the extent our negligence directly caused or materially increased that loss.

6. Stop conditions and incidents

6.1 Either party may require an immediate pause where testing is causing or creates a credible risk of material harm, unexpected data exposure, third-party impact, legal uncertainty or a live security incident.

6.2 The party requesting the pause should identify the affected activity where practicable. A pause does not make earlier activity within the ROE retrospectively unauthorised.

6.3 If we observe evidence of an apparently unrelated live compromise, we will stop affected testing and notify the Customer’s emergency contact. Further incident-response work is outside scope unless agreed.

6.4 The Customer must not treat activity that complies with the ROE as hostile or unauthorised, and must use reasonable efforts to prevent an automated or third-party enforcement process from escalating known test traffic.

7. Data, credentials and evidence

7.1 Security Testing may reveal Customer Content, personal data, secrets, credentials, source code, system configuration and other Confidential Information. We will access and retain only what is reasonably necessary for the agreed testing and evidence.

7.2 We will not intentionally collect bulk production data where a smaller, redacted or synthetic sample is sufficient.

7.3 Where access to personal data or another person’s content is necessary to validate an issue, we will minimise the access and avoid using or disclosing the information for any unrelated purpose. The DPA applies where we process personal data on the Customer’s behalf.

7.4 We will protect evidence using access controls and encryption appropriate to its sensitivity. High-risk evidence should be transferred through an agreed secure channel rather than ordinary email.

7.5 Credentials created for testing should be unique to the engagement. Unless the Customer instructs otherwise, we may disable, return or securely delete them when no longer needed.

7.6 Unless the ROE states another period, we will delete raw captures and working evidence containing Customer Content within 30 days after delivery of the final report, except where retention is required by law, needed for an agreed retest, or reasonably necessary for a dispute. Final reports and ordinary business records are retained under the applicable retention schedule.

7.7 We may retain a sanitised record of a finding, technique or lesson learned that contains no Customer identity, Customer Content, credentials or Confidential Information.

8. Reports and severity

8.1 The Deliverables will be those stated in the SOW and may include a written report, executive summary, technical findings, reproduction guidance, evidence, remediation recommendations and presentation.

8.2 Unless the SOW states another method, severity is our professional assessment based on exploitability, impact, environmental context and available evidence. A CVSS score, where included, is one input rather than a guarantee of business impact.

8.3 The Customer should review factual and environmental context promptly. We will correct a material factual error, but a reasonable professional disagreement about severity is not by itself a defect.

8.4 Reports describe conditions observed during a time-bounded assessment. A clean result does not prove that a system is secure or free from vulnerabilities.

9. Remediation and retesting

9.1 Remediation is the Customer’s responsibility unless expressly included.

9.2 A retest covers only findings and scope identified in the SOW. New features, architectural changes or newly discovered issues may require additional work.

9.3 A finding is considered remediated where the relevant exploit path is no longer reasonably reproducible under the retest conditions. We do not warrant that the underlying component contains no other weakness.

10. Disclosure and publicity

10.1 Findings, reports and vulnerability information are Confidential Information. Neither party may publicly disclose the Customer’s findings or identify the engagement without the other’s written consent, except where required by law.

10.2 The parties may agree a coordinated disclosure process for a vulnerability affecting a third-party product or the wider public. No disclosure to a third-party vendor or coordinator should identify the Customer without permission unless legally required.

10.3 Nothing prevents us from making a mandatory disclosure or reporting an imminent and serious risk where required by law. Where lawful, we will consult the Customer first.

11. No guarantee and residual risk

11.1 Security Testing is sampled, time-bounded and dependent on scope, access and technique. It cannot identify every vulnerability, compromise, configuration issue or attack path.

11.2 New vulnerabilities may arise after testing. The Customer remains responsible for ongoing risk management, patching, monitoring, secure configuration and incident response.

11.3 A report is not a certification of compliance unless the SOW expressly identifies a specific certification service and criteria.

12. Liability and authority-related claims

12.1 Liability is governed by the General Terms.

12.2 The Customer indemnity in the General Terms applies where a third party alleges that agreed Security Testing was unauthorised because the Customer lacked or exceeded authority. This allocation is fundamental because we rely on the Customer’s scope and authorisation.

12.3 We remain responsible for activity that materially exceeds the ROE because of our failure to use reasonable care and skill, subject to the Contract’s liability provisions.

13. Contact

Security-testing coordination may be sent to security@amber.systems. Contract and commercial enquiries may be sent to hello@amber.systems.