Policies, disclosure and data handling.

Responsible disclosure

If you have found a vulnerability in a system Surge operates, we want to hear about it, and we will not take legal action against anyone who reports in good faith under this policy.

In scope

• Systems on domains Surge owns and operates, listed at [asset list URL]
• Our public web properties, APIs and infrastructure

Out of scope

• Client systems. We test those only under contract, and you must not test them
• Denial of service, volumetric testing, or anything degrading availability
• Social engineering of Surge staff, suppliers or clients
• Physical attacks against our offices or personnel

What we ask

• Report to security@surge.red, encrypted to [PGP key fingerprint] if the finding is sensitive
• Give us enough detail to reproduce it, and stop once you have proven the issue
• Do not access, modify or retain data belonging to anyone else
• Give us 90 days before public disclosure, and we will keep you updated throughout

What we commit to

• Acknowledgement within 2 working days
• An initial assessment and severity rating within 10 working days
• Credit in our advisory, if you want it
• No legal action for good-faith research conducted within this policy

security.txt

Serve this at /.well-known/security.txt. It is the machine-readable form of the policy above, and researchers look for it before they look at anything else.

Contact: mailto:security@surge.red
Contact: https://surge.red/policies/#disclosure
Expires: 2027-01-01T00:00:00.000Z
Encryption: https://surge.red/.well-known/pgp-key.txt
Acknowledgments: https://surge.red/policies/#thanks
Preferred-Languages: en
Canonical: https://surge.red/.well-known/security.txt
Policy: https://surge.red/policies/#disclosure

The Expires field is mandatory and must be in the future, so set a calendar reminder to roll it, because an expired file reads as an abandoned one.

Data handling

An offensive engagement produces the most sensitive material a client will ever hand over: working exploits against their live systems. How we hold it matters more than how we find it.

What we collect

• Scope material you provide: source code, credentials, architecture documents
• Evidence generated during testing: requests, responses, screenshots, proof-of-concept code
• The minimum personal data needed to run the engagement and contact your team

How we hold it

• Engagement data is stored in [named jurisdiction and provider], encrypted at rest
• Access is limited to the named engineers on your engagement, on a documented least-privilege basis
• Multi-factor authentication is mandatory for every system holding client material
• Client data is never used to train models, and is never sent to third-party services without your written agreement

Retention and destruction

• Evidence and credentials are destroyed 30 days after the final report, unless you ask us to hold them for retest
• Reports are retained for [period] so we can support you, then destroyed
• A destruction certificate is issued on request
• Client-supplied credentials are rotated by you at engagement close, and we will remind you

If we get it wrong

• We notify you of any breach affecting your data without undue delay and within 24 hours of becoming aware
• You receive what we know, what we are doing, and what we recommend, in writing

Rules of engagement

Every assessment is governed by a signed rules-of-engagement document. No testing of any kind begins before it exists. At minimum it records:

• Authorisation. Who is granting permission, and their authority to do so on behalf of the asset owner
• Assets. Exactly what is in scope, by domain, IP range, application or physical location
• Exclusions. What must not be touched under any circumstances
• Window. The dates and hours testing may occur
• Third parties. Written consent from any cloud provider or supplier whose systems are implicated
• Escalation. Named contacts on both sides, reachable out of hours
• Stop conditions. What causes us to halt immediately, and how we tell you
• Evidence handling. What we may retain, and for how long

Testing a system without the owner's authorisation is a criminal offence in Sri Lanka under the Computer Crime Act No. 24 of 2007, and under equivalent legislation elsewhere. We decline engagements where authorisation cannot be evidenced. [Confirm current statutory references with counsel.]

Privacy notice

This covers personal data collected through surge.red. Engagement data is governed by your contract and the data handling section above.

What we collect and why

• Details you submit through the scoping request form (name, role, organisation, email), used solely to respond to your enquiry
• [Analytics, if any. If you deploy analytics, name the provider, the lawful basis and the retention period here.]

Lawful basis

• Legitimate interest in responding to a business enquiry you initiated, and your consent where given

Your rights

• Access, correction, erasure, and objection to processing
• Exercise them by writing to privacy@surge.red; we respond within [statutory period]
• You may complain to the Data Protection Authority of Sri Lanka

Controller

• [Registered entity name and company number], 215 R A De Mel Mawatha, Colombo 03, Sri Lanka
• Data protection contact: [named person or role]

Terms of engagement

Scope and fees

• Every engagement is fixed-scope and fixed-fee, agreed in writing before work starts
• Changes to scope are agreed in writing and may change the fee and the timeline
• Retest of remediated findings is included, within [period] of report delivery

What we do not promise

• An assessment is a point-in-time exercise against an agreed scope. It cannot prove the absence of vulnerabilities
• A clean result means we found nothing exploitable in that scope, in that window, with that effort

Confidentiality

• Mutual, surviving termination by [period]
• We name you as a client only with written permission

Independence

• Surge builds software as well as testing it. Where Surge built the system under test, we disclose it in writing before the engagement and staff the assessment with engineers independent of the delivery team
• Where you need demonstrable independence for an auditor or regulator, we will say so plainly and recommend a third party

Insurance and liability

• Professional indemnity: [insurer, limit, policy number]
• Public liability: [insurer, limit]
• Cyber liability: [insurer, limit]
• Certificates provided on request during procurement

Large clients will ask for these before contract. If the cover does not yet exist, get it before pitching regulated buyers. A bank's procurement team will not proceed without it.

Sub-processors

Third parties that may process client data during an engagement. Enterprise questionnaires ask for this list by name, purpose and location.

• [Cloud hosting: provider, region, purpose]
• [Reporting or collaboration tooling: provider, region, purpose]
• [Any LLM or code-analysis service used in review, with the data boundary stated explicitly]

Given the site claims LLM-assisted review, the third bullet is not optional. Enterprise buyers will ask whether their source code reaches a model provider, under what terms, and whether it is retained. Answer it here before they have to ask.