Trust portal
Check our work. Then check us.
Verify a DXCL certificate, see what our reports look like, and read exactly how we test. Everything an investor, buyer or auditor needs before trusting a certificate with our name on it.
Verify a certificate.
Type the ID printed on the certificate, or scan its QR code with your phone camera. You will see who it was issued to, what was tested, and whether it is still valid today.
How the check works
The check runs in your browser. Each record is encrypted with its own certificate ID, so only someone holding the ID can read it, and we never publish a list of the companies we test. If a check fails, email [email protected] with the ID and a person will confirm it.
What a certificate means, and what it does not.
A certificate is a dated record of one engagement. It is useful because it is specific. Read it the way you would read an audit opinion: scope first, then dates.
It confirms
- DXCL tested the systems listed in the scope, in the testing window shown.
- Testing combined automated attacks with manual testing of every page and endpoint in scope.
- Every finding was reported to the holder with its impact and a fix.
- When the fix check is complete, the date it was done.
- The date it stops counting as evidence: 3 to 6 months after the report, set per engagement.
It does not claim
- That the system has no vulnerabilities. No honest test can promise that.
- Anything about systems outside the listed scope.
- Anything about changes shipped after the testing window.
- To be a CERT-In audit certificate, an ISO 27001 certification or a SOC 2 report. It complements those; it does not replace them.
- Issued
On the day we deliver the report.
- Fix check
We confirm your fixes hold, and the record shows the date.
- Valid
For 3 to 6 months, depending on what we found and how fast fixes can land.
- Expired or renewed
When it lapses, a full retest renews it with a new ID.
- Revoked
If a certificate is misused or the scope was misrepresented, we revoke it and the check says so.
See a report before you buy one.
Every engagement ends with two documents and a call. The sample shows both for a fictional company, with one finding written out in full.
- Managerial report
- For founders and leadership: overall risk in plain words, findings by severity, what to fix first and why it matters to the business.
- Technical report
- For your engineers: each finding with the affected endpoint, the request that proves it, the impact, a severity rating and the fix.
- Walkthrough call
- The testers who found each issue explain it live and answer your developers’ questions.
- Fix check
- Included. We re-test what you fixed and record the result before the certificate is final.
How we test.
Tools find the known patterns quickly. People find the logic flaws tools miss. We use both on every engagement, and our test plans follow public standards your auditors already recognise.
Web applications
OWASP Web Security Testing Guide (WSTG) and Application Security Verification Standard (ASVS).
APIs
OWASP API Security Top 10.
Mobile apps
OWASP Mobile Application Security Verification Standard (MASVS) and Testing Guide (MASTG).
AI and LLM systems
OWASP Top 10 for LLM Applications and MITRE ATLAS.
Network and cloud
NIST SP 800-115 and the Penetration Testing Execution Standard (PTES).
IoT devices
OWASP IoT Security Testing Guide (ISTG).
On request, we map findings to the controls your auditors ask about, such as ISO/IEC 27001 Annex A, SOC 2, PCI DSS and the reasonable security safeguards required by India’s DPDP Act.
How findings are rated.
Each finding gets a CVSS base score and a severity, then we adjust for what the issue means for your business. The report explains every adjustment.
| Severity | What it usually means | Typical example |
|---|---|---|
| Critical | Direct path to sensitive data or full control, with little effort or skill. | Unauthenticated access to every customer’s records. |
| High | Serious impact that needs some access or a specific condition. | One logged-in customer can read another customer’s invoices. |
| Medium | Real weakness with limited impact, or one that needs chaining with others. | Missing rate limits that make password guessing practical. |
| Low | Small risk on its own; worth fixing in normal work. | Detailed error messages that reveal software versions. |
| Informational | No direct risk; a hardening step or good practice. | Security headers that could be tighter. |
Rules of engagement.
The commitments behind every test, written down before anything starts.
Written approval first.
We test only after you approve the scope, the environment and the testing window in writing. Nothing outside that scope is touched.
Certified people, named to you.
Every engagement is run by certified security testers. You meet them on the scoping call and talk to them directly throughout.
Your data stays yours.
We use what we see only to test and report. Findings go to the people you name, and we never share your results without your consent.
Found a vulnerability in DXCL?
We test other people’s systems for a living, so we expect ours to be tested too. Tell us and we will look into it.
Machine-readable contact: security.txt
Please include
- The affected URL or system and what an attacker could do.
- Steps to reproduce, with requests or screenshots.
- How we can reach you for questions.
Please do not
- Access, change or keep data that is not yours.
- Run denial-of-service, spam or social engineering tests.
- Share the issue publicly before we have fixed it.
For AI agents and tools.
The same information, in formats software can read.
Tell us what you’re shipping.
A fundraise, an enterprise deal, an AI launch. Send a line about your product and we come back with a fixed-price scope within 48 hours.
Or email [email protected]