Coordinated disclosure policy

veil.pritect.ai and the application programming interface served from it. That is the whole of Pritect Veil as we operate it, and a finding anywhere in it is in scope.

The boundaries below are not evasions. Each one is somebody else's to receive, and sending it to us delays the person who can fix it.

• The Pritect platform and Pritect Beacon. They are separate products at separate domains, and this policy does not speak for them
• Anything belonging to a sub-processor. A finding in a provider's own service belongs to that provider's disclosure programme, and the Sub-processor list names every provider we use
• A customer's own connected system, such as a Microsoft SharePoint tenant an administrator of that customer has authorised. Clause 1.2 of the Sub-processor list explains why: those systems are processed for the customer, under the customer's own agreement with that provider, and are not ours to invite testing of
• Anything you reach by using credentials that are not yours, whoever gave them to you

If you test Pritect Veil within this policy and report what you find to us, that testing is authorised. It is the prior written agreement that clause 2.4 of the Acceptable use policy requires, and you are not in breach of that clause.

We will not pursue a report made in good faith, and we will not ask anyone else to. If a third party raises a claim about testing that stayed within this policy, we will say that the testing was authorised.

Good faith means you told us, you told us first, and you stayed inside the limits in clause 2.2.

Clause 2.1 applies to testing that stays inside every one of the limits below. Testing that does not is outside this policy, and clause 2.4 of the Acceptable use policy applies to it in full.

• Accessing, changing or keeping another organisation's data beyond the minimum needed to demonstrate the finding, or keeping any of it after you have reported
• Degrading the service, including load testing, scanning at a volume we have not agreed, and anything that denies the service to a customer
• Social engineering or phishing directed at our people, at a customer, or at anyone working for either
• Physical attempts against premises, and attempts against equipment belonging to a person rather than to the service
• Testing against an organisation's account or tenant that you do not control

Write to security@pritect.ai. It is the address our security.txt file names, the address the trust centre publishes, and the address clause 5.1 of the Acceptable use policy already routes security reports to. There is no form and no account needed.

We read reports in English.

• Where you found it: the address, the endpoint, or the part of the application
• What you did, in enough detail that we can reproduce it
• What you were able to reach, and what someone could reach from there
• Anything that separates a real finding from a scanner's opinion, such as a request and the response to it
• How you would like to be credited, if you would like to be

Do not send us another person's personal data. If a demonstration produced some, describe what you saw and tell us where to look rather than attaching it.

If you are holding a copy of anything you reached, delete it once we confirm we can reproduce the finding, and tell us you have. Veil exists to keep other people's personal data out of a disclosure, and a report about Veil is not the place to make a new copy of some.

Reported security issues are acknowledged within two business days. That is a person confirming your report arrived and is being read. It is not a verdict on it.

We aim to tell you within five business days whether we accept the finding and, if we do, how serious we think it is. Where a finding takes longer to reproduce than that, we will say so inside the same period rather than going quiet.

We ask you to wait ninety days from the date of your report before publishing it. If a fix needs longer, we will ask you, and any extension is by agreement rather than by our decision alone.

We will tell you when the fix ships. If we decide not to fix something, we will tell you that instead, and why, so that you can decide what to do with it knowing where we stand.

If your report shows that customer personal data has been exposed, our obligation to notify the affected customers is clause 6 of the Data processing agreement. It runs on its own clock, independently of this policy, and nothing here delays it or narrows it.

The list below is a preference, not a refusal. We read everything sent to us. But a report of one of these, on its own and with nothing shown about what it lets someone do, is unlikely to be accepted, and saying so here is fairer than saying it after you have spent an evening on it.

• The output of an automated scanner, sent on without a demonstration of impact
• A missing or misconfigured response header, with no demonstrated impact
• The absence of rate limiting on an endpoint that needs no authentication, unless you can show what it enables

Impact is what turns any of these into a finding. Show us what it lets someone do and we will treat it as one.

We do not run a bug bounty and we do not pay for reports. There is no budget behind this policy, and saying so on the first day is better than leaving it open and disappointing you on the last.

What we offer is credit in this document. If you would like to be named once a finding is fixed, say so in your report and we will name you here. If you would rather not be, we will not, and we will not name you by accident either.