Evaluation and security review questions

This page is the one a reviewer opens, so it is written for a reviewer: what we claim, what we do not claim, who to email, and an explicit list of the things you will have to ask us because they are not on the website. Nothing here is softened to survive a first read.

Is SecureAI Guard SOC 2 or ISO 27001 certified?

This site does not state that it holds any certification, and you should not infer one from the presence of compliance content. That is written into llms.txt as guidance for assistants summarising this site, because the failure mode we most want to avoid is a machine inferring a certification from a page that merely discusses one.

Our audit position — SOC 2, ISO/IEC 27001, ISO/IEC 42001, including where the honest answer today is "not yet" — belongs on the trust page. That page is currently withheld from search results because it still carries unanswered items, and we would rather publish it with visible gaps than publish a certification we do not hold.

If a certification is a hard gate for your review, email security@secureaiguard.com and ask where we actually are. You will get a straight answer, including if the answer is that we are not there yet.

Do the compliance pages mean you are compliant with those frameworks?

No, and the distinction is deliberate enough to be written into how the site is organised. The compliance section explains what the EU AI Act, the NIST AI Risk Management Framework, ISO/IEC 42001 and the GDPR require of an organisation deploying LLM applications — the reader's obligations, with dated citations to the primary text. It says nothing about our own audit status, which lives on /trust.

"What do I have to do about the AI Act" is a compliance question. "Are you SOC 2 audited" is a trust question. A vendor that answers the second by pointing at the first is doing something you should notice.

Can we get a DPA, and will you complete our security questionnaire?

Yes to both, by email. Write to security@secureaiguard.com or use the contact form.

Send your own questionnaire rather than waiting for a completed template. It is faster, and it tells us which controls your review actually turns on — a pre-filled vendor pack is optimised for the questions the vendor wanted to answer. The same applies to the DPA: send yours if you have one.

Is there an API reference we can read before we commit?

Not yet, and that is stated on the documentation page rather than implied by absence. The endpoint-by-endpoint reference — authentication and key rotation, request and response schemas, error codes, rate limits and 429 handling, and an OpenAPI document — is named there as not published.

We flag this because it changes how you should evaluate everything else. Until that reference exists, no comparison table on this site asserts a SecureAI Guard capability that you could click through and verify, which is why the comparison pages compare approaches rather than putting our own product in a feature grid. A capability grid whose supporting reference does not exist is a set of claims, and a reviewer who finds that mismatch is right to discount everything around it.

How do we report a vulnerability in your service?

Email security@secureaiguard.com with enough detail to reproduce it — the affected endpoint or page, the steps, and what you observed — and include a proof of concept if you have one. We will acknowledge the report, keep you informed while we investigate, and credit you publicly if you would like to be credited.

We will not pursue legal action against anyone who reports in good faith, gives us a reasonable opportunity to fix the issue before public disclosure, and does not access, modify or delete other people's data while researching it. Please do not run automated scanning that degrades the service for others, and do not test with real customer data. The full statement is on the security page, and the machine-readable version is at /.well-known/security.txt.

What should we ask you that this website does not answer?

Take this list into the first call. Every item is something we have chosen not to state on a public page because we do not have a published, verifiable answer for it, and every item is a question that changes an architecture decision:

• Supported models and frameworks. Which providers and framework versions have actually been tested, and at which attachment point. /integrations/supported-models-and-frameworks is the page that will hold the matrix; it is unfilled today.
• Failure behaviour. Fail open or fail closed when the layer cannot decide, what the timeout is, and what gets logged when it happens.
• Streaming. Whether output-side checks buffer the response or inspect it incrementally, and whether that is configurable per route.
• Retention. How long prompt content is held, what is content versus metadata, and what a deletion request actually removes.
• Training. Whether customer content is used to improve anything, in writing.
• Processing regions and subprocessors. See data residency for what is open.
• Detection thresholds. What the defaults are, whether they are tunable per route, and what the false-positive rate was on the traffic they were tuned on.
• Upgrade and deprecation policy. How breaking changes are announced and how long a version is supported. The changelog is where that will be recorded.

If you get a vague answer to any of them, from us or from anyone else in this category, that is your finding.

Where to go next

• Pricing — plans, what each includes, and its own FAQ. Pricing questions are answered there rather than duplicated here.
• Data handling questions — what the layer sees and what happens to it.
• Deployment and architecture — where it sits and what self-hosting needs.
• Security practices — disclosure, contacts, and the design properties worth checking in any vendor.