01How we work securely
Security is part of how we build, not a stage at the end. In summary:
- Access — least privilege, multi-factor authentication on every business account, and access removed the day someone leaves an engagement.
- Client environments — we work in your accounts and tools where you prefer, with credentials you issue and can revoke.
- Encryption — HTTPS everywhere; data encrypted at rest in the services we use.
- Secure delivery — code review, dependency scanning and secrets management on the software we build, to OWASP ASVS as a baseline.
- Incidents — a written response plan; we notify affected clients without undue delay and report to CERT-In and the Data Protection Board where the law requires.
We build to frameworks such as ISO/IEC 27001 and OWASP ASVS. We do not currently hold a security certification.
02Reporting a vulnerability
Email connect@xterraedze.com with the subject "Security report". Please include the affected URL or system, a description of the issue and its impact, steps to reproduce, and how we can reach you. Do not include personal data you may have encountered beyond what is needed to show the issue.
03What happens next
Acknowledge Target: 3 working days
We confirm we have your report and who is handling it.
Triage Target: 10 working days
We reproduce the issue, assess severity and tell you our assessment.
Fix
We fix it in line with its severity and keep you updated. We may ask you to confirm the fix.
Disclose and credit
We agree the timing of any public disclosure with you, and credit you if you wish.
04Scope
In scope: this website and its forms, and systems operated by Xterra Edze. Out of scope: client systems (report those to the client), third-party services we use, denial-of-service, social engineering or phishing of our people, physical attacks, and findings with no security impact such as missing headers on static pages without a demonstrated exploit.
05Rules of engagement
- Test only against your own accounts and data; stop and report as soon as you reach anyone else's.
- Do not degrade service, destroy data, or keep more data than needed to show the issue — and delete it afterwards.
- Give us reasonable time to fix before disclosing publicly.
- Do not demand payment in exchange for details of a vulnerability.
06Safe harbour
If you make a good-faith effort to follow this policy, we will consider your research authorised, we will not pursue or support legal action against you for it, and we will work with you to understand and fix the issue. If a third party brings action against you for research that followed this policy, we will make clear that it was authorised.
07security.txt
Our security contact is also published in machine-readable form, as RFC 9116 specifies:
# Xterra Edze — security contact (RFC 9116)
Contact: mailto:connect@xterraedze.com?subject=Security%20report
Expires: 2027-09-23T00:00:00.000Z
Preferred-Languages: en, hi
Canonical: https://xterraedze.com/.well-known/security.txt
Policy: https://xterraedze.com/legal/security