Authorized Testing Policy
We test only what we are authorized in writing to test, within an agreed scope, under agreed rules. This policy explains what that means in practice.
1. Purpose of this policy
Security testing involves deliberately attempting actions that would be unlawful without permission. In most jurisdictions, unauthorized access to a computer system is a criminal offence regardless of intent, and permission from someone who lacks the authority to grant it is not a defence. This policy sets out how CyberCache establishes lawful authorization before any testing takes place, and what boundaries apply once it does.
It applies to every engagement we undertake, including success-based engagements. Commercial terms never alter the authorization requirements described here.
2. Written authorization is mandatory
We do not begin testing on the strength of a conversation, an email expressing enthusiasm, or a signed commercial proposal alone. Before any testing activity, we require written authorization that:
- identifies each asset to be tested with enough precision to remove ambiguity, such as domains, hostnames, IP ranges, application environments, or cloud accounts;
- is granted by a person entitled to grant it for those specific assets;
- states the period during which testing is permitted;
- is accompanied by rules of engagement agreed by both parties.
Where any asset is operated by a third party — a hosting provider, a platform vendor, a payment processor, or a service on which your product depends — that third party\u2019s own permission is also required. We will ask you to obtain it, and we will not proceed on the assumption that your contract with them is sufficient.
2.1 Who can authorize
Authorization must come from someone with actual authority over the assets concerned. In practice this is normally a director, an officer, or a senior technology or security leader with delegated authority. If we have reasonable doubt about whether the person authorizing testing holds that authority, we will ask for confirmation from someone who plainly does, and we will delay testing until we have it.
3. Scope
Every engagement has a written scope. It lists in-scope assets, out-of-scope assets, the environments concerned, the accounts and roles provided to us, and the permitted testing window.
We test what is in scope and nothing else. If we identify something outside the agreed scope that appears to warrant attention — an exposed service on an adjacent host, a related domain, a third-party integration behaving unexpectedly — we will tell you it exists and ask whether you wish to extend the scope. We will not test it in the meantime.
Scope may be changed during an engagement, but only in writing and only with the same authorization requirements as the original scope.
4. Rules of engagement
Rules of engagement are agreed and signed before testing begins. They record at minimum:
- the authorization itself, and who granted it;
- in-scope and out-of-scope assets;
- the techniques we are permitted to use, on the basis that anything not listed is not permitted;
- the testing window, including any restricted hours;
- named contacts on both sides, and an escalation route available during the testing window;
- how critical findings are communicated before the report;
- stop conditions, and the process for pausing and resuming testing;
- how evidence is collected, stored, transmitted, and disposed of;
- confidentiality obligations on both sides.
5. Excluded by default
The following are excluded from all engagements unless explicitly agreed otherwise in writing:
- Social engineering of any kind, including phishing, vishing, pretexting, and any technique directed at your personnel rather than your systems.
- Physical intrusion, including access to premises, tailgating, and tampering with hardware or physical media.
- Denial-of-service testing, including volumetric, application-layer, load, and stress testing.
- Destructive actions, including deletion or corruption of data, encryption of data, and ransomware simulation.
- Persistence, including installing implants, creating accounts for later use, or retaining access beyond what evidencing a finding requires.
- Exfiltration of production personal data beyond the minimum required to evidence a finding.
- Testing third-party infrastructure you cannot lawfully authorize us to test.
- Any technique not listed as permitted in the rules of engagement.
Some of these can be considered as separate, specialist engagements where a suitable process, legal review, and your explicit written approval are all in place. They are never included silently.
6. Conduct during testing
We aim to cause no disruption. Testing is performed with care, rate-sensitive operations are approached cautiously, and we prefer a representative non-production environment where one exists and is genuinely representative.
If we cause or suspect we have caused unintended impact — instability, data corruption, an outage, or a security control triggering in a way that affects your users — we stop the activity immediately, notify your named contact through the agreed escalation route, and assist in understanding and resolving what happened.
If we discover evidence that your systems have already been compromised by someone else, we stop, preserve what we have observed, and notify you promptly. Incident response is a distinct discipline with distinct obligations, and we will not begin investigating on our own initiative.
7. Handling of data and evidence
We collect only the evidence necessary to demonstrate a finding, and we minimise the retention of any data belonging to you or your users. Where we incidentally access personal data, we limit what is retained, record what happened, and inform you.
Evidence is stored on encrypted media, shared only through the channel agreed in the engagement documents, and disposed of according to the retention terms recorded there. Findings and reports are confidential to you; we do not publish, disclose, or reference them without your written permission, which is why our public sample report uses a fictional subject rather than a redacted real engagement.
8. Limits of any assessment
A security assessment examines a defined scope during a defined period using the access and information available at the time. It cannot prove the absence of vulnerabilities, and we do not represent that it does. We provide no warranty, express or implied, that any system is secure, fully compliant, or free of defects.
We do not issue certificates, seals, badges, or accreditation, and we do not claim certifications or memberships that we do not hold. Our methodology is published so it can be assessed on its content instead.
9. Reporting a security issue to us
If you believe you have found a vulnerability in our own website or infrastructure, we would like to hear about it. Please write to info@cybercache.cc with enough detail for us to reproduce the issue.
We ask that you act in good faith: report privately and give us a reasonable opportunity to respond before any disclosure; do not access, modify, or exfiltrate data that is not yours; do not degrade our services or those of anyone else; and confine your testing to systems that are plainly ours.
We will acknowledge your report, keep you informed of progress, and credit you if you would like to be credited. To be clear about what this is: this is an invitation to report, not a bug bounty programme. We do not operate a paid bounty, and this policy does not create any commitment to payment or any legal safe harbour beyond our own undertaking not to pursue good-faith researchers who follow these guidelines.
10. Reporting a suspected misuse of our name
If someone claims to be testing your systems on our behalf and you did not engage us, treat it as hostile and tell us at info@cybercache.cc. We will confirm promptly whether any engagement exists.
11. Changes to this policy
We may update this policy. The effective date at the top of this page reflects the current version. The terms applicable to an engagement are those recorded in the engagement documents signed by both parties, which prevail over this page in the event of any inconsistency.
12. Contact
Questions about this policy can be sent to info@cybercache.cc.