Source plan:
documents/IMPLEMENTATION/threat-modeling-maturity-implementation-plan.md— Lane C2. Machine-readable pointer:web/public/.well-known/security.txt(RFC 9116), reachable athttps://opusplatforms.co.uk/.well-known/security.txt.
Our commitment
Opus Platforms takes the security of our platform, our workers, and our employer customers seriously. We welcome reports from independent security researchers who discover a genuine vulnerability in our systems and will work with you to understand and resolve the issue quickly.
Scope
In scope:
https://opusplatforms.co.ukand all first-party subdomains (e.g.api.opusplatforms.co.uk,n8n.opusplatforms.co.uk) serving production traffic.- The Opus Platforms REST API, MCP tool surface, and WhatsApp/WebChat AI assistant integrations reachable through those domains.
- Authentication, authorization, session management, and payment/payroll-adjacent flows (shift acceptance, timesheet approval, invoicing, payouts).
Out of scope:
- Third-party vendor infrastructure we integrate with but do not operate (Stripe, Modulr, Staffology, Twilio, AWS managed services, Cloudflare) — report those directly to the vendor.
- Denial-of-service, volumetric, or resource-exhaustion testing against production.
- Social engineering, phishing, or physical-security testing against Opus staff, workers, or employer customers.
- Automated vulnerability scanning that generates significant traffic volume without prior coordination (contact us first to agree scope and rate limits).
- Findings that require a jailbroken/rooted device or a MITM position you created yourself (e.g. a self-signed certificate you installed).
- Issues in non-production environments (staging, dev, Mode B/local-hosting) unless they demonstrate a vulnerability that also exists in production.
How to report
Email security@opusplatforms.co.uk with:
- A clear description of the vulnerability and its potential impact.
- Step-by-step reproduction instructions (proof-of-concept code/requests welcome).
- The affected URL(s), endpoint(s), or component(s).
- Your contact details for follow-up questions.
Please encrypt sensitive reports where practical, and avoid including real worker/employer personal data in your report — use synthetic or your own test account data instead.
Do not publicly disclose a vulnerability until we have confirmed a fix is live, or 90 days have elapsed since your report, whichever is sooner (a standard coordinated-disclosure window; we will ask for more time only if genuinely needed and will explain why).
Safe harbour
If you make a good-faith effort to comply with this policy during your security research, we will not pursue legal action against you for that research. Good faith means:
- You do not access, modify, or exfiltrate data belonging to other users beyond what is strictly necessary to demonstrate the vulnerability.
- You stop testing and notify us immediately upon discovering any exposure of production worker/employer personal data, payment data, or credentials.
- You do not perform actions that could degrade service for real users (no destructive testing against production, no DoS).
- You give us a reasonable opportunity to investigate and remediate before any public disclosure.
- You comply with applicable law — this policy does not authorise action against any system or data we do not own or control.
This safe harbour is intended to be interpreted consistently with the spirit of disclose.io's standard terms.
Response SLAs
| Stage | Target |
|---|---|
| Acknowledgement of report | 2 business days |
| Initial triage / severity assessment | 5 business days |
| Status update cadence while open | Every 2 weeks minimum |
| Remediation of a confirmed Critical/High finding | 30 days (may extend for complex fixes, with status updates) |
| Remediation of a confirmed Medium/Low finding | 90 days |
Severity is assessed using the same CVSS-informed approach documented in
documents/SECURITY/RISK-ASSESSMENT-METHODOLOGY.md.
Recognition
We do not currently operate a paid bug-bounty programme. We maintain the right to offer discretionary recognition (e.g. a public thank-you, swag) for high-quality reports, with your consent.
Private bug-bounty programme (planned, not yet live)
A private programme on a platform such as Intigriti or HackerOne is planned for
closer to public launch, once there are live customers and traffic to justify
external tester access (see the threat-modeling maturity plan, Lane C2). Until
that programme is live, this VDP and the security@opusplatforms.co.uk mailbox
are the only disclosure channel — this is intentional, not an oversight, and is
tracked as a launch-readiness dependency rather than an immediate blocker.
Related documents
documents/SECURITY/RISK-ASSESSMENT-METHODOLOGY.md— severity scoring.documents/SECURITY/accepted-risks.md— risks we have consciously accepted.web/public/.well-known/security.txt— RFC 9116 machine-readable pointer to this document.documents/RUNBOOKS/security/security-incident-data-breach.md— what we do when a reported issue turns out to be a personal-data breach (72h ICO clock); sibling runbooks cover compromised admin, malicious MCP tool and payroll fraud (OPS-4829).