What this policy is
1.1 This policy explains how to report a security vulnerability in gamechanger360.co.uk, what we ask of you while you are looking for one, and what we commit to in return. It is written for security researchers, and for anyone who finds something by accident and wants to do the right thing with it.
1.2 It has one purpose above the others: to make it safe to tell us. Section 6 is a safe harbour statement, and it is the part of this document that matters most.
1.3 The policy is published by GAME CHANGER 360 LTD, trading as GAMECHANGER360. Our registered particulars and our other contact addresses are on our legal notice page.
1.4 Machine-readable contact details are published at https://gamechanger360.co.uk/.well-known/security.txt, in the format set by RFC 9116, so that a scanner or a tool can find the right address without a person reading this page first.
1.5 This page is general information and not legal advice, and it is not a contract. It is a public statement of how we will act, and a researcher acting in good faith within it is meant to be able to rely on it.
What is in scope
2.1 In scope: this website at gamechanger360.co.uk, meaning the pages it serves, the static assets and images served from the same domain, and the public endpoints behind its forms, which are the enquiry form, the newsletter subscription and its confirmation link, and the Integrity Readiness Check.
2.2 Also in scope, to the extent that we control it: the configuration of the domain itself, including its DNS records, the mail authentication records that govern who can send email as us, the TLS configuration and the HTTP security headers this site sets.
2.3 What we are most interested in: anything that exposes what somebody submitted through a form, anything that runs script in another visitor's browser, anything that lets a request be read, altered or forged, server-side request forgery, a misconfiguration that exposes a secret or an internal endpoint, a path that lets mail be sent that appears to come from our domain, and any design fault that lets a single ordinary request consume a disproportionate amount of resource. Describe that last one rather than demonstrate it at scale.
2.4 If you are not sure whether something is in scope, ask at security@gamechanger360.co.uk before you start. We would rather answer a question than receive a report about a system we are not in a position to act on.
Our product applications are separate systems
3.1 360 Academy, 360 Report, 360 Sentinel and 360 Intelligence run on their own subdomains and are separate applications, not part of this website. They are authenticated services holding learning records, reports, case files and evidence, and where an application is deployed by a federation, league, club, regulator, university or player association, that organisation is the controller of the data in it. Section 3 of our privacy notice explains that split.
3.2 They are therefore outside the testing scope of this policy. This policy does not authorise you to test them, and we could not give that authorisation on behalf of an organisation whose deployment it is.
3.3 Reports about them are welcome all the same. If you know of a vulnerability in one of those applications, whether you found it in your own account, in a deployment you are entitled to use, or without any testing at all, send it to security@gamechanger360.co.uk. We will route it to the team that owns the application and, where a deploying organisation is the controller, to that organisation, and we will keep you informed exactly as section 9 describes.
3.4 One thing should never happen, under any policy: no test should touch a live case file, a report, an evidence file or a reporter's identity. There is a person behind each of those, and the cost of getting it wrong falls on them rather than on us.
What is out of scope
4.1 The following are outside this policy, and nothing here authorises you to test them:
- systems that are not ours, including our hosting provider, our email provider, our domain registrar and the platforms where we keep a profile. Each has its own disclosure programme, and only they can authorise testing against their systems
- any customer deployment, any customer data and any infrastructure a customer owns
- our people, our advisers, their personal accounts and their devices
- our offices, our registered office, our post and anything reachable through a place or a person rather than through a system
- third-party websites we link to, and content we do not host
4.2 We will read, acknowledge and thank you for the following, but on a site like this one they do not usually amount to a vulnerability on their own, because the impact has to be shown rather than assumed: a missing or additional HTTP header with no exploit that it would have prevented; unvalidated output from an automated scanner; self-XSS; clickjacking on a page with no state-changing action; a rate limit you consider too generous, without a demonstration of what it lets you do; software or framework version disclosure; a view about our mail authentication records unaccompanied by a working sending path; and a TLS or certificate finding reported as a scanner grade alone.
4.3 If one of those does have real impact here, show us the impact and we will treat it as a vulnerability. That list is about evidence, not about dismissal.
How to report
5.1 Email security@gamechanger360.co.uk. One report per issue, in English, from an address we can reply to. There is no form to fill in and no account to create.
5.2 A report is easiest to act on when it contains:
- the affected URL, endpoint or record, and the parameter or field involved
- the type of issue, in a sentence
- steps to reproduce it, precise enough that we can follow them without guessing, including any request or payload you used
- what the impact is: what an attacker could actually read, change, take or break, and what they would need in order to do it
- anything that affects severity, such as whether authentication is required or whether it is reachable by a visitor who is not signed in
- a screenshot, a short video or a log extract where it helps, and your test account details where you used one
- how you would like to be credited, or that you would rather not be
5.3 Please do not include real personal data belonging to anyone else. If the proof involves somebody's record, describe it rather than paste it: the field names, the number of records you could reach and how you reached them tell us everything we need. Redact what you must include. Sending us another person's data in order to prove a point creates a second problem on top of the first one, and it takes you outside section 6.
5.4 Please do not use the enquiry form, the newsletter, a social media message or 360 Report for a security report. 360 Report exists for integrity concerns in sport and is monitored through a different process, so a security report sent there does not reach the people who can fix it.
5.5 We do not publish a PGP key, so please do not encrypt your first message. If a report is sensitive enough that you want an encrypted channel, say so in a short email and we will agree one with you before you send the detail.
Safe harbour
6.1 This is the commitment. Where you act in good faith and within this policy, we will treat your research as authorised, and:
- we will not bring a civil claim against you, and we will not support one brought by anyone else, arising from that research
- we will not report you to the police or to any other authority for it, and we will not support a prosecution of you for it
- we will not ask your employer, your university or your hosting provider to act against you
- we will treat your access as authorised for the purposes of the Computer Misuse Act 1990, so that it is access we have permitted rather than unauthorised access, and any act you carry out within this policy is one we have consented to
- we will treat the research as permitted rather than as a breach of clause 6 of our terms of use, which otherwise prohibits testing or circumventing a security control. To the extent of the research this policy authorises, this policy prevails over that clause
- and if a third party brings a claim against you for research we authorised, we will confirm that it was authorised, in writing and publicly, if you ask us to
6.2 Those undertakings are conditional, and section 7 sets out the conditions in full. They are deliberately short, and none of them asks anything unreasonable of a researcher.
The conditions of the safe harbour
7.1 You keep within the safe harbour in section 6 where:
- you are trying to find and report a vulnerability, not to cause harm, to extract a payment, or to gain a commercial or personal advantage
- you do not access, copy, alter, delete or retain data belonging to anyone else. Use your own accounts and your own test data. If you come across somebody else's personal data, stop, do not save it, and tell us in general terms what you saw
- you do not degrade, interrupt or reduce the quality of the service for anyone else, and you keep your traffic to something a person using the website could plausibly generate
- you stop as soon as the vulnerability is confirmed. A single proof that it exists is enough. There is no need to see how far it goes, to pivot to another system, to escalate a privilege or to maintain access
- you leave nothing behind: no backdoor, no persistent change, no defacement and no deletion. If a test writes data, tell us what it wrote and where, so we can clean it up
- you use none of the methods listed in section 8
- you report to us promptly, and you give us reasonable time to fix the issue before you tell anyone else, as section 10 describes
- and you comply with the law. This policy speaks for our systems only. It cannot authorise you in respect of anyone else's, and it does not relieve you of obligations under data protection law
7.2 The limits of what we can promise, stated plainly. We can give this undertaking only for ourselves. We cannot bind our hosting provider, our other suppliers, a customer that has deployed one of our products, or a law enforcement authority acting on its own initiative. Nor can we give away rights that belong to a third party whose data is involved, which is why the condition about other people's data is the one condition we cannot soften.
7.3 If you step outside this policy, we will look at what happened and at what you did next before we do anything at all. A researcher who oversteps by accident, stops and tells us is in a very different position from someone who does not, and we will treat them differently. None of this is aimed at honest mistakes.
7.4 If you are not sure whether what you plan to do is within this policy, ask at security@gamechanger360.co.uk first. A question in advance is always safer than an assumption, and we answer them.
What we will do, and when
9.1 We are a small company. We would rather state a period we can keep than one that sounds impressive, so these are commitments rather than aspirations:
- we acknowledge your report within five working days of receiving it, by reply to the address you wrote from
- we give you an initial assessment within ten working days, telling you whether we have reproduced the issue and how we currently rate it
- we keep you informed at least every twenty working days while the issue is open, and we tell you when it is fixed
- we tell you if we decide not to fix something, and why. That is an answer we are willing to give and explain, rather than leave a report unanswered
9.2 Working days means Monday to Friday, excluding public holidays in England. The mailbox is monitored during UK business hours. It is not a 24-hour channel and it is not an emergency line.
9.3 If you believe the vulnerability is being actively exploited, say so in the subject line. We will move faster than these periods, not slower.
9.4 There is no paid bounty programme. We do not pay for reports, and we would rather say that at the outset than let you spend an evening on the assumption that we might. When we can run one properly, this page will say so.
9.5 Credit is offered to anyone who wants it. Tell us the name or handle you would like us to use, and whether you want it linked, and we will use it when we describe the fix. If you would rather not be named, we will not name you. Either way, we will thank you properly.
9.6 We fix in order of severity and exploitability, not in order of arrival. A serious issue is fixed as quickly as we can build and ship the fix; a minor one may wait for the next ordinary release.
Coordinated disclosure
10.1 We ask you not to publish, share or demonstrate a vulnerability until it is fixed, or until ninety days have passed since we acknowledged your report, whichever comes first.
10.2 Ninety days is a working default and not something we will hide behind. Where a fix is straightforward we will not use the whole window. Where a fix is genuinely harder than that, we will come back to you before day ninety, explain what is holding it up and propose a new date. We will not ask you for an open-ended extension, and we will not ask anyone to stay quiet indefinitely.
10.3 After the window we will not object to you publishing, and we do not ask you to submit a draft for our approval. We would like to see it beforehand if you are willing, so that we can check the technical detail and correct anything that is wrong, but that is a request rather than a condition.
10.4 We ask that a public write-up leaves out anyone else's personal data, and anything that would identify a reporter, a case or an organisation using one of our products, even where you came across it legitimately.
10.5 Where a vulnerability affects a customer deployment, the deploying organisation has its own notification duties and its own timetable, and it may need longer than we do. We will tell it, and we will tell you that we have.
10.6 If we end up disagreeing about timing, we would rather talk about it than let a date pass in silence. Tell us what you intend to do and when, and we will do the same.
Keeping this policy current
11.1 The date shown with this page is the date of the current version. We review the policy when the website changes materially and at least once a year, and we keep the expiry date in our security.txt file in step with that review.
11.2 A change to this policy does not withdraw the safe harbour from research that was already under way. Research is judged against the version of this policy that was published when it started.
11.3 Questions about this policy go to security@gamechanger360.co.uk. Questions about personal data go to privacy@gamechanger360.co.uk, and our privacy notice explains how we handle it.