International Security Journal hears exclusively from Boris Dzhingarov, Founder and CEO of ESBO Ltd.
Procurement teams are leaning hard on AI these days to build their vendor shortlists, which completely changes how we buy software.
Think about it: a buyer types a few business requirements into an enterprise AI tool, and they get a polished summary of top candidates in seconds.
Then, security teams get handed this magically curated list.
Suddenly, you’re under immense pressure to rubber-stamp the risk profile so the business can just move forward.
Visibility vs verifiability
Here’s the problem. Generative AI tools scrape public-facing content to build these summaries, which means they’re great at highlighting feature lists, integrations and shiny compliance badges.
However, they totally fail at parsing the actual nuances of a SOC 2 Type II report.
They definitely can’t evaluate how deep a vendor’s incident response plan actually goes and this creates a massive, dangerous gap between marketing hype and technical reality.
Since AI just amplifies what is visible on a website, it completely ignores what’s actually verifiable in a production environment.
Let’s say a vendor claims “robust data protection,” the AI flags them as highly secure, however, without digging into the underlying controls, your security team has no idea if that protection relies on modern cryptography or some outdated, vulnerable protocol.
So, to actually protect the enterprise, security leaders have to demand rigorous proof.
Implementing this can help to reduce incident risk and cuts out post-deployment rework, whilst also speeding up confident decisions, such as turning security from a bottleneck into a revenue driver.
The proof file: Seven essential artifacts
Getting past the marketing spin takes a standardised approach.
Forward-thinking vendors are already using centralised Trust Packs to proactively share their evidence.
Due to this, you must demand the following seven artifacts before you even think about approving new software.
The seven artifacts include:
1) Security architecture summary
You need a clear diagram and a plain-English explanation of how their app and infrastructure actually stay safe from external threats.
- Get the exact encryption standards for data at rest and in transit
- Look into how they handle access control, for example, whether they actually support SSO and MFA out of the box
Red flag: Throwing around marketing fluff like “military-grade encryption” while dodging questions about specific standards like AES-256 or TLS 1.3.
2) Data flow and retention map
Where does your corporate data go and how long does it stay there? Get the documented lifecycle.
- Pin down the exact data residency locations
- Define hard retention periods for after the contract ends
Red flag: Vague policies claiming data gets deleted “upon request” is not enough, you need to implement hard, enforced retention limits.
3) Logging and auditability proof
Show evidence that the platform gives your internal SOC enough visibility.
- Which admin actions actually trigger logs?
- How easy is it to export this stuff to your SIEM tools?
Red flag: Vendors charging premium fees just to give you basic security logs or SSO integration.
4) Pen test summary and remediation posture
Ask for a recent third-party penetration test summary, plus their process for fixing whatever was found.
- Check the date of the last test and the methodology used
- Look for defined SLAs for patching critical flaws
Red flag: Handing over a flawless test with absolutely zero issues and the Founder dragging their feet when you ask for their timeline to fix known bugs.
5) Software supply chain and SBOM visibility
Don’t skip getting a proper Software Bill of Materials (SBOM), because you need to know exactly which open-source and third-party libraries are baked into their code.
- Check to see if their documentation actually follows CISA’s supply chain risk guidelines
- Find out exactly how they keep an eye on upstream bugs, since those can easily become your problem
Red flag: Brushing you off by saying their code is “100% proprietary,” therefore they supposedly don’t need to track dependencies at all.
6) Incident response commitments
How does the vendor handle breaches and how will they talk to you when things go south? Get a formal declaration.
- Nail down the exact timeframe for breach notifications
- Get them to map out exactly how they plan to talk to you if an outage or attack happens
Red flag: Saying they will reach out “promptly” instead of putting a hard 24- or 48-hour SLA in writing.
7) Compliance mapped to controls
We want actual audit reports, not just website badges.
- Ask for the full SOC 2 Type II or ISO 27001 report
- Make sure the scope of the audit is clearly defined
Red flag: Slapping a compliance logo on their homepage but refusing to hand over the underlying report under an NDA.
Validation vs hype
Going through this pile of evidence requires some real structure, so you should definitely map your checks against well-known industry frameworks.
For instance, lean on NIST SP 800-161 for supply chain risk management and always cross-reference what the vendor claims against their actual audit reports.
If a vendor boasts about comprehensive cloud security, but their SOC 2 report conveniently excludes their primary hosting environment from the scope, the evidence just doesn’t back up the story.
Defining ownership
Clear internal ownership stops delays in their tracks and ensures the vetting is actually comprehensive.
Split the review process up across the relevant departments.
Security should evaluate the architecture, pen test results, SBOM and logging capabilities.
At the same time, your IT team should be looking at how hard it is to integrate, whether it plays nice with your identity management and if their uptime promises hold water.
Legal needs to review data privacy commitments, liability clauses and the compliance scope.
Finally, procurement manages the overall vendor relationship, contract SLAs and the cost structures.
When everyone knows exactly what their job is, the whole process moves a lot faster.
Measuring the vetting process
You also need to track specific metrics so your vendor risk management program actually stays effective.
- Monitor the percentage of vendors who can hand over a complete Proof File within 48 hours
- Measure how many unknown risk factors you’re forced to accept at sign-off
- Track your average time-to-risk decision, since you want to ensure security reviews aren’t stalling procurement
- Keep an eye on post-deployment rework caused by undiscovered security gaps. These metrics give you a crystal-clear picture of whether your program is working.
Demanding evidence
AI-driven procurement definitely speeds up the discovery phase, but it absolutely cannot replace technical validation.
Security teams have to enforce strict evidence requirements to keep corporate infrastructure safe.
So, choose vendors who package verifiable facts instead of just telling compelling stories.
Ultimately, putting in this extra effort means you’re building a tough, resilient supply chain that won’t crumble the second a modern threat hits.
