Security and Vulnerability Reporting

01Our security commitment#

A credential registry is only worth anything if it can be trusted. We take care to protect the site, the registry and the data they hold, and we welcome reports from people who find a weakness.

02Scope of coordinated disclosure#

Scope matters legally. Safe harbour in Section 7 covers research inside the scope and does not cover research outside it.

If you are not sure whether something is in scope, ask before testing. Asking is always safe.

03Who may test, and who may not#

This page is not a general permission to test the site. Testing is authorised only for the people and in the way the Acceptable Use Policy sets out (Section 4 there). In short:

• Authorised: IICTP staff and contractors within a written scope, outside firms under a signed engagement, and anyone to whom the Security Office has given specific written permission in advance.
• Narrowly permitted: a good-faith researcher with no permission may do only the low-impact observation described in Section 5 below, and report it.
• Not permitted: penetration testing, automated scanning, fuzzing, load or denial-of-service testing, credential attacks, tampering with registry records or badges, social engineering and phishing, attacks on our providers, and evading protections. These need written permission first.

If you want to carry out any prohibited test, ask first at security@iictp.org. We will tell you the scope, window and rules, or decline. Do not start before you have it in writing.

04How to report#

Email security@iictp.org with a clear subject line. If you wish to encrypt your message, ask for our key first. [Encryption key and a security.txt file to publish.] Do not send a report through a public channel, a social platform or the contact forms of third parties.

A report that is incomplete is still welcome. We will ask for what is missing.

05Rules for research#

These rules define what is authorised. Staying inside them is what brings you under the protection in Section 7.

• Test only against your own data and accounts, and stop as soon as you have shown the issue. Do not go on to see how far it reaches.
• Do not access, change, copy or delete other people’s data, or the registry’s. If you reach personal data by accident, stop, do not keep or share it, and tell us.
• Do not run automated vulnerability scanners, fuzzers, exploit tools or load tests, at any volume, without written permission from the Security Office. Observe the site as an ordinary visitor and with your browser’s own tools.
• Do not go beyond proving that the weakness exists. Do not exploit it to read data, run code, change a record or reach another system.
• Do not use a finding to demand payment or other advantage from us. A demand of that kind is extortion in many countries and takes you outside the safe harbour.
• Keep the details private until we have fixed the issue, or until 90 days after your report, whichever is first. After that you may publish. If we have not fixed it by then, we ask that you tell us before you publish.
• Follow the Acceptable Use Policy.

06Response timeline and process#

These are targets, not guarantees, because a fair promise is one we can keep. If we miss one, we will tell you why.

We will treat your report and identity as confidential and will not share your identity with a third party without your agreement, unless the law compels it.

07Safe harbour: what we promise and what we cannot#

If you act in good faith, stay in scope and follow the rules in Section 5, then in respect of your research we:

• consider it authorised access, so we will not treat it as unlawful access under the terms of the site or under the Acceptable Use Policy;
• will not bring or support any civil or criminal action against you for it;
• will say, if another party starts action over it, that you acted within these rules.

08How we protect the site#

Statements here are limited to what is true of the site today.

• Small surface. The public site is a static front end that collects very little data and has no sign-in or payments, which keeps the exposed surface small.
• Tamper evidence. Registry records carry a verification hash, and the digital badge carries a decentralized identifier, so alteration can be detected by anyone who checks.
• Data minimisation. Personal data is limited to what is needed, as the Privacy Policy describes. Data we never collect cannot be lost.
• On-device processing. The eligibility guide runs in your browser; your answers do not reach our servers.

09If something goes wrong#

If an incident affects personal data or the integrity of the registry, we will investigate, contain it, correct the record and notify those who must be told.

After an incident we will record what happened and what we changed. We keep that record so that the facts can be shown later.

10Contact#

Security reports go to security@iictp.org. For privacy requests, write to privacy@iictp.org. For legal notices, legal@iictp.org.

↺Version history