Vulnerability disclosure policy

Realizer Services Inc. publishes this policy for AccessPoint and the Realizer platform. Last reviewed 2026-09-26.

1. Why this policy exists

AccessPoint handles access-to-information and privacy case files for government organisations. If there is a weakness in it, we would rather hear it from you than read about it later. This policy tells you what we run, what you may test, how to report what you find, what we will do, and how quickly.

We follow the coordinated vulnerability disclosure practices set out by CISA, the NSA, JPCERT/CC, NCSC-NL and NCSC-UK. We do not require non-disclosure agreements, and we do not ship silent fixes: when we fix a reported vulnerability, we say so in an advisory.

2. Scope

2.1 In scope

Testing the product itself. AccessPoint is not a hosted service: it deploys into the operator's own Azure subscription and Microsoft 365 tenant. If you want to test the application rather than our platform endpoints, deploy your own instance and test that. We will help you get one running — ask at security@realizer.io. Findings from your own instance are fully in scope, including the deployment template, the database schema, the API, the portal, the web part and the worker image.

We do not limit participation by nationality, age or affiliation, and we accept anonymous reports. We may be unable to work with anyone we are legally barred from dealing with.

2.2 Out of scope

• Any AccessPoint deployment operated by one of our customers. Those run in the customer's own Azure subscription and Microsoft 365 tenant, hold real case files about real people, and we cannot authorise you to test them. Do not probe a customer's instance. If you believe you have found a weakness in a specific organisation's deployment, report it to that organisation; you may also tell us (section 2.3).
• Microsoft services (Azure, Microsoft 365, Entra ID, Microsoft Graph, the commercial marketplace). Report those to the Microsoft Security Response Center at https://msrc.microsoft.com/report.
• Third-party components we do not control, including the Syncfusion libraries and their CDN. Tell us anyway if it affects AccessPoint users — we will coordinate with the vendor.
• Findings without a security impact, including: missing security headers with no demonstrated exploit; weak TLS ciphers with no demonstrated attack; SPF, DKIM or DMARC configuration reports on domains that send no mail; rate-limit observations on anonymous endpoints without a demonstrated impact; version-banner disclosure; issues that require an out-of-date or unpatched browser; clickjacking on pages with no state-changing action; self-XSS; social-media account takeover claims; automated scanner output with no analysis.
• Denial of service, load testing, and physical or social-engineering attacks against Realizer, our customers, our staff or our suppliers (section 3.3).

2.3 If your finding is about a customer's deployment

Tell the organisation that operates it. If you tell us instead, we will try to reach that organisation through the contacts we hold, we will not identify you to them without your permission, and we will not test their environment ourselves without their written authorisation.

3. Rules of engagement

3.1 Test broadly, exploit minimally

We would rather you used the techniques a real attacker would use than worked around an arbitrary boundary. In exchange, stop at proof: do only as much as is necessary to demonstrate that the vulnerability exists.

3.2 Protect data

If you encounter personal data, credentials, case content or anything else that is not yours, stop, do not save it, and tell us immediately. Do not access more records than you need to show the problem. Delete anything you retrieved once your report is acknowledged, and tell us that you have.

3.3 Do not

• Introduce malware, or leave any code or account behind.
• Copy, modify, encrypt or delete data in a system that is not yours.
• Make configuration changes to our systems.
• Access accounts, mailboxes or tenants that are not yours.
• Repeatedly access a system beyond what your testing needs, or share your access with anyone else.
• Run brute-force or credential-stuffing attacks.
• Run denial-of-service or load tests.
• Use social engineering, phishing, or physical intrusion against Realizer, our customers or our suppliers.
• Publish before we have agreed a disclosure date (section 6).

4. How to report

Email security@realizer.io. This mailbox is separate from customer support and is monitored for security reports only.

Encryption. If you would rather not send details by plain email, ask us for another channel and we will arrange one.

Anonymous reports are accepted. You will not be asked to identify yourself, though we cannot credit you (section 7) or tell you about the fix if we cannot reach you.

A report we can act on contains, at minimum:

• what the issue is, in one or two sentences;
• where it is (URL, endpoint, package and version, or file and line);
• how to reproduce it, step by step;
• what an attacker gets out of it.

An ideal report adds: a minimised proof of concept, your assessment of the impact and who is affected, a CVSS vector if you use one, any logs or timestamps of your testing (so we can tell your traffic from an attacker's), and how you would like to be credited.

Please write in English or French.

5. What you can expect from us

We will tell you if a target is going to slip, and why, before it slips. If we decide not to fix something, we will tell you that too, with our reasoning, and you are free to say so publicly under section 6.

Severity is assessed on the impact to the operators of AccessPoint and the people whose information it holds, not on how hard the bug was to find.

6. Coordinated disclosure

• Default: 90 days from our acknowledgement, or the day the fix is published, whichever comes first.
• We will agree an earlier or later date with you where it makes sense — for example, more time for a fix that needs a schema migration in every customer's database, or less time for something already being exploited.
• If a vulnerability is being exploited, we will move immediately and will not hold a fix or an advisory for an embargo.
• Long embargoes do not make anyone safer; the more people who know, the more likely a leak.
• We will not ask you to sign a non-disclosure agreement as a condition of reporting, and we will not use one to keep a fixed vulnerability quiet.
• Our advisories are published on a public page with no login and no paywall.
• If we and you cannot agree, you may publish at the end of the agreed window. We would rather coordinate than argue.

7. Credit

We name reporters in the advisory when they want to be named, in whatever form they ask for (name, handle, organisation, or nothing). Tell us in your report.

We do not run a paid bug bounty today. If that changes, this policy will say so before it takes effect.

8. Safe harbour

If you make a good-faith effort to comply with this policy during your security research, Realizer Services Inc. will consider your research authorised, will work with you to understand and resolve the issue quickly, and will not initiate or recommend legal action against you in relation to that research. If a third party brings an action against you for activity carried out in accordance with this policy, we will make this authorisation known.

This authorisation is ours alone to give. It does not cover, and we cannot give authorisation for:

• systems operated by our customers, including any AccessPoint deployment in a customer's own Azure subscription or Microsoft 365 tenant (section 2.2);
• Microsoft's services and infrastructure, which are governed by Microsoft's own terms;
• any activity outside this policy, including the prohibited activities in section 3.3.

Nothing here limits the rights of any third party, and this authorisation does not override any law. If you are unsure whether something is in scope, ask us first at security@realizer.io — we would rather answer a question than read about a misunderstanding.

9. security.txt

Our machine-readable security contact is published at /.well-known/security.txt, as RFC 9116 requires, on both realizer.io and api.realizer.io.

10. Advisories

Published advisories are listed at /security/advisories, with an Atom feed at /security/advisories/feed.atom. There is no login and no paywall. Customers running an affected version also see the advisory inside AccessPoint, and customers who have registered a security contact receive it by email.