Legal · Acceptable use
Rules for using this website, its verification registry, APIs and any public submission forms.
At a glance
A plain summary. The full text below is what applies.
Read the standards, verify credentials, apply for exams or partnership in good faith.
No denial-of-service, vulnerability exploits, credential stuffing or malicious payloads.
Do not harvest the registry or harvest email addresses without written agreement.
We may block access, revoke credentials, report misuse or take legal action.
This policy keeps the site, and the credential registry in particular, fair, reliable and trustworthy. It applies to everyone who uses the site and forms part of the Terms and Conditions.
Testing a system means sending it input meant to find or use a weakness. It is lawful only when the owner has authorised it. This section says what we authorise, to whom, and what we forbid. It is deliberately precise, because unauthorised access to a computer is an offence in most countries, and a clear rule is what lets us act against it and lets honest researchers know where they stand.
| Who | Allowed | Condition |
|---|---|---|
| IICTP staff and contractors | Yes | Within a written scope and dates set by the Security Office |
| An outside firm or person engaged by IICTP | Yes | Only under a signed engagement with a written scope, rules of engagement, test window, source addresses and a named contact. Nothing outside that document is authorised |
| Any other person, by written permission | Yes | Only if the Security Office has agreed in writing, before you start, to the specific tests, targets and dates. Ask at the security address. Silence is not permission |
| A researcher acting in good faith, with no permission | Narrowly | Only the low-impact observation allowed on the Security and Disclosure page, and only by following its rules |
| Everyone else | No | Any testing beyond the above is unauthorised |
| Activity | Examples |
|---|---|
| Penetration testing and exploitation | Using a weakness to gain access, escalate privileges, run code or read data, even to “prove” it |
| Automated vulnerability scanning | Running scanners, crawlers that probe paths, or exploit frameworks against the site or its address range |
| Fuzzing and injection attempts | Sending malformed or malicious input in bulk to forms, query strings, headers or the registry search |
| Denial of service and load testing | Flooding, stress tests, amplification, resource exhaustion, or any test meant to slow or stop the site |
| Credential attacks | Guessing or stuffing passwords, tokens, keys or any identifier |
| Tampering with the registry or badges | Attempting to create, change, forge or remove a record, hash or digital badge, or to defeat the verification check |
| Social engineering and phishing | Deceiving staff, partners or visitors, or sending phishing messages that use our name, including “simulations” |
| Physical and network attacks | Entering premises, intercepting or redirecting other people’s traffic, attacking DNS, or testing our hosting and service providers |
| Evading protections | Bypassing rate limits, blocks, bot controls or access restrictions |
| Keeping or sharing what you reach | Copying, retaining, selling or publishing data you were not meant to see, or using a finding to demand payment or advantage |
Asking is always safe. To request permission, or to report something you found, write to security@iictp.org and read the Security and Disclosure page first.
Ordinary browsers, accessibility tools, search-engine crawlers and AI crawlers are welcome to read the public pages of the site, and our robots.txt says so. That welcome has conditions, which are what separate a crawler from an attack. A crawler must:
robots.txt and any limits we publish, and keep its request rate low enough not to affect other visitors, so that it does not amount to the load testing forbidden in Section 4;Two limits apply to every automated tool, including those we welcome:
robots.txt is a technical signal and not a licence. Being allowed to fetch a page does not give ownership of it, or any right beyond the Terms and Conditions.
For permission to do anything beyond this, such as higher volume, write to registry@iictp.org.
If you see a credential being misrepresented, exam content being shared, or the site being misused, tell us at legal@iictp.org with the details and any links. For a security weakness, use the process on the Security and Disclosure page instead.
We respond in proportion to the harm and to whether it was deliberate. Steps may include the following, and we may skip steps for serious or repeated cases.
| Step | What it means |
|---|---|
| Request | We ask you to stop or correct the problem, for example to remove a misleading claim |
| Restriction | We limit or block access to the site or registry for you or your network |
| Registry action | We mark a record, or follow the credential rules where a holder has misused a credential |
| Referral | We tell the affected people, employers or authorities, where the law allows or requires |
| Legal action | We take steps to protect our rights and the integrity of the standard |
We may update this policy as the site changes. The version history at the foot of the page lists earlier versions.
| Version | Date | Change |
|---|---|---|
| 0.10 | 16 October 2026 | First published. |
| 0.9 | 16 October 2026 | First published. |