Neutrality and platform security

What we publish

We publish only facts that can be verified from public sources, always with a date and the source named. For example: whether a vendor has published a data processing agreement, whether it states that it uses customer data to train models, where it processes data, and which permissions it requests during an integration.

These are facts as of a given day, not a security rating. The sentence “the vendor has not published a subprocessor list” can be verified. The sentence “this tool is secure” cannot, so we will not write it.

Where we have a conflict of interest

We sell our own products and assess other people's products at the same time. This conflict is built into our business model. It cannot be removed, only shown honestly.

• Each of our own products is labeled as an operator product wherever it appears next to someone else's.
• We do not rank our own products higher in any listing because they are ours.
• We do not accept payment for a better result, a higher position or the removal of a finding. Payment covers carrying out the assessment, never its outcome.
• If we assess a product from a company we have a partnership agreement with, we say so in the report.

What we do not publish

• Security rankings of companies. A result applies to a scope, a date and a specific use case, so it cannot be turned into a table ranked from best to worst.
• Technical details of vulnerabilities before they are fixed and without the system owner's consent.
• Client reports. A report belongs to the client who ordered it. We do not turn it into marketing material without written consent, and the examples in our materials are synthetic.
• A status without a date and scope. A badge that does not say what it covers and when is misleading.

Reporting a breach of neutrality

If you believe a publication is inaccurate, biased or based on a wrong finding, write to arlets@yesfor.ai.

1. We confirm receipt of the report and tell you who is handling it.
2. We check the finding at the source, not on the basis of the report alone.
3. If we were right, we explain why and show the evidence.
4. If we were not, we correct the publication and mark what changed and when.
5. The change history stays visible. We do not erase the trace of a correction.

Security of the platform itself

arLET’S holds things that are worth more together than apart: client database configurations, data boundary test results, contracts. We treat this as elevated risk and apply to ourselves the same requirements we set for the systems we check.

• The application has no key that bypasses the database access rules. The public form writes through a single function with a narrowly defined permission.
• We do not store raw IP addresses, only an irreversible hash of them, and only to limit abuse.
• Access to client systems is read-only by default, and we show the permission scope before you connect.
• Tests that touch a running system require a written authorization and technically will not start without it.
• The activity log is append-only. A record cannot be changed or deleted from within the application.

What we do not have yet

It is more honest to write this down than to stay silent and let you assume otherwise.

• We do not have SOC 2 or ISO 27001 certification. When we do, we will say so here, with a date.
• We have not yet had an external penetration test of our own platform.
• We do not have a status page with incident history. It is planned.