European startups now have to audit every AI vendor baked into their product, and that audit reaches deeper into your app's codebase than most founders expect.
Direct answer: If your startup's website or app uses any third-party AI feature — a chatbot, a recommendation engine, a content generator, an embedded model API — you are now expected to document what that AI system does, where it sits in the EU AI Act's risk tiers, and whether your vendor can prove compliance. For most early-stage European startups this means an inventory exercise first, then targeted fixes to the product itself, not a full legal overhaul.
Through the second half of 2026, EU AI Act compliance commentary has repeatedly flagged the same shift: European businesses of every size, not just large enterprises, are now having to audit their AI vendor stack for AI Act exposure for the first time. This is a change in scope, not just intensity. Compliance work that used to sit exclusively with banks, insurers, and large platforms is now landing on seed-stage and Series A startups that quietly wired an AI vendor into their onboarding flow, their support widget, or their content pipeline eighteen months ago and never revisited the decision. The commentary doesn't hand founders a single number to hide behind — no "X% of startups are exposed" statistic exists that we can point to honestly — but the pattern it describes is consistent and specific: audits are starting now, they are starting from a position of incomplete inventory, and they are surfacing product-level decisions that engineering teams made without legal in the room. That last part is the piece founders tend to miss. This isn't a paperwork problem you can solve with a policy document; it's a problem that lives inside your codebase, your API integrations, and the way your mobile app actually behaves.
What "auditing your AI vendor stack" actually means
An AI vendor audit, in the form commentary is describing, is not a single event. It's a recurring discipline with three parts: inventory, classification, and verification.
Inventory means listing every place in your product where an AI system makes or influences a decision that reaches a user — not just the obvious chatbot, but the fraud-scoring call inside your payments flow, the ranking algorithm in your feed, the auto-tagging step in your content moderation pipeline, and any embedded model from a subprocessor your main vendor quietly relies on. Most founders can name two or three AI touchpoints from memory. A real inventory usually finds twice that many once you trace API calls through your backend.
Classification means placing each of those touchpoints into the AI Act's risk framework — unacceptable risk (banned outright), high-risk (subject to conformity assessments, documentation, and human oversight requirements), limited risk (transparency obligations, like disclosing that a user is talking to a bot), and minimal risk (no specific obligations). Most consumer-facing startup features land in limited or minimal risk, but a surprising number of hiring, credit-scoring, or health-adjacent features drift into high-risk territory without anyone intending it.
Verification means going back to each vendor and asking for the paperwork: their own risk classification, their technical documentation, evidence of testing, and contractual commitments about what happens if the classification changes. This is the step most startups have never done, because until now nobody asked.
Why this is happening to smaller companies now, not just enterprises
The AI Act's phased enforcement timeline is one driver — obligations for different risk categories come into force on staggered dates through 2026 and beyond, and regulators, auditors, and enterprise customers doing vendor due diligence are all now asking questions earlier in that timeline than expected. The other driver is simpler: enterprise customers are pushing the audit requirement downstream. If a startup sells into a larger European company, that company's own compliance team increasingly asks the startup to demonstrate its AI vendor posture as part of procurement — meaning the audit obligation arrives via a sales contract long before it arrives via a regulator's letter.
Why this specifically matters to startup founders in Europe
Founders read AI Act coverage and assume it's a large-enterprise problem because that's who gets named in the coverage. That assumption is exactly what's breaking down. A few reasons this now lands squarely on startups building web and mobile products:
You didn't choose your AI stack as a compliance decision — you chose it as a speed decision. Early-stage teams integrate whichever AI vendor ships the fastest feature. Nobody was asking "what risk tier is this" in month three of a startup's life. That's rational at the time and creates exposure now.
Your app is probably shipping AI features you don't think of as "AI." Autocomplete, smart search, personalized push notifications, spam filtering, image tagging — plenty of ordinary mobile app features run on a model under the hood, licensed from a vendor who may or may not have done their own homework. An audit doesn't care whether you marketed it as "AI-powered."
Fundraising and enterprise sales now touch this directly. European investors doing diligence on a Series A round, and European enterprise buyers doing vendor security review, are starting to ask AI-specific questions that didn't exist on their checklists two years ago. A founder who can produce a clean AI vendor inventory in that conversation moves faster than one who has to go build one under deadline pressure.
Multi-country teams multiply the surface area. A startup based in one EU country, with app users across several others and a vendor stack split between US and European providers, has more jurisdictional threads to track than a single-market business. This is exactly the profile of a lot of European startup teams building web and mobile products for a continental or global audience.
What changes in practice for your website or app
This is where the audit stops being a legal exercise and becomes a product engineering one. Concretely, a founder going through this process for the first time should expect the following to change.
Your architecture needs to expose its AI dependencies
If your AI vendor calls are scattered across services with no consistent logging or labeling, an audit takes weeks instead of days, and every future audit takes weeks again. Teams that have already invested in cloud-native development practices — clean service boundaries, centralized API gateways, structured logging — find this dramatically easier, because every AI call already passes through a traceable point instead of being buried inside a monolith. If your app's architecture doesn't have that separation yet, this is a legitimate forcing function to build it, alongside the broader case for mobile app development done with maintainability in mind from the start rather than retrofitted under regulatory pressure.
User-facing disclosure becomes a design requirement, not a legal footnote
Limited-risk AI systems — most chatbots and generative features fall here — carry a transparency obligation: users need to know they're interacting with AI. That's a UI decision as much as a legal one. It affects your chat widget's opening message, your app's onboarding copy, and how prominently you disclose AI-generated content. Bolting this on as a hidden terms-of-service clause doesn't satisfy the spirit of the requirement and increasingly doesn't satisfy enterprise buyers reviewing your product either.
Accessibility and compliance obligations start to overlap
Startups that have already gone through a WCAG 2.2 accessibility compliance pass on their website tend to have an easier time here, and not coincidentally — both processes require the same underlying discipline: documenting how your interface behaves for every category of user, keeping decision logic auditable, and treating compliance as a design constraint rather than an afterthought. If your team has never done a structured accessibility or compliance review of your product, this is a reasonable moment to combine the two.
Vendor contracts need an actual review, not a rubber stamp
Most startups sign a vendor's standard terms without asking what happens if that vendor's own AI Act classification changes, or what documentation they'll provide if you get audited. Going forward, a basic compliance checklist for any new AI vendor should include: their risk classification and the reasoning behind it, whether they use subprocessors that introduce their own models, their data retention and training-data practices, and a contractual commitment to notify you of classification changes. This isn't unique to consumer AI vendors either — the same discipline applies if your product touches operational systems built by outside vendors, the way a custom software platform for logistics tracking, routing, and dashboards might rely on an AI-driven routing engine that needs the same scrutiny.
Someone on your team needs to own this on an ongoing basis
A one-time audit goes stale the moment you add a new vendor or ship a new feature. The founders handling this well are assigning ownership — often a technical co-founder or lead engineer, not outside counsel — to keep a living inventory that gets updated every time an AI-touching integration changes.
What to actually do about it, in order
- Build the inventory first, before anything else. Walk your codebase and your vendor contracts and list every AI touchpoint, however minor. Don't skip anything because it "isn't really AI" — let the classification step decide that.
- Classify each item against the AI Act's risk tiers, even roughly. You don't need outside counsel for a first pass; you need to know which items are worth escalating.
- Request documentation from every vendor whose AI feature you can't fully explain yourself. If a vendor can't produce basic documentation, that's a signal worth acting on regardless of the regulatory question.
- Fix the architecture gaps that made step 1 hard. If tracing AI calls through your app took longer than it should have, that's a structural problem worth solving once, properly.
- Add disclosure and oversight where the classification calls for it, prioritizing user-facing AI features first since those carry the clearest transparency obligations.
- Put a recurring review on the calendar. Quarterly is reasonable for an early-stage team; monthly if you're shipping AI features frequently.
A note on scope discipline
Founders sometimes over-correct once they realize the exposure and try to rebuild their entire stack "for compliance." That's usually the wrong instinct at seed or Series A stage. The proportionate response is targeted: fix the traceability gaps, fix the disclosure gaps, document the vendor relationships, and keep building. A full architectural rewrite is rarely what an audit actually requires, and treating it that way burns runway you don't have to spend.
Common mistakes founders make on their first pass
A handful of patterns show up repeatedly once teams start this work, and knowing about them ahead of time saves a lot of wasted effort.
Treating the inventory as a legal document instead of a technical one. The most useful inventory is written by someone who can trace an actual API call from your frontend through your backend to the vendor endpoint that handles it. A version written from memory in a meeting room, without opening the codebase, reliably misses things — usually the subprocessor layer, and usually a feature that shipped quietly as a fast follow-up to something else.
Assuming "we don't call it AI" means it doesn't count. Marketing language has no bearing on classification. A "smart" search bar, an "auto" content suggestion, a "personalized" feed — these are AI systems in the eyes of the regulation whether or not your landing page uses the word. Founders who filter their inventory by their own marketing copy end up with an incomplete list.
Doing the audit once and considering it finished. The AI Act obligation isn't a box you check once; it's a posture you maintain. A new integration added six months after your audit, without anyone re-running the process, recreates the exact blind spot the original audit was meant to close. This is why ownership matters more than the initial audit itself — the team that assigns a clear owner and a recurring cadence rarely ends up surprised later.
Confusing vendor reputation with vendor compliance. A well-known, well-funded AI vendor is more likely to have done its own homework, but "more likely" is not the same as "verified." Founders sometimes skip the verification step for large vendors and apply it only to smaller, less familiar ones — when in reality every vendor in the inventory deserves the same basic documentation request, regardless of size or brand recognition.
Letting the audit stall because "we're waiting on legal." Legal input is valuable for edge cases and for finalizing contract language, but the inventory and initial classification work doesn't require it. Startups that wait for a lawyer's calendar to open before starting the technical inventory lose weeks they didn't need to lose — the two tracks can run in parallel.
A note on European jurisdictional variation
Even though the AI Act is EU-wide legislation, enforcement mechanisms and supervisory authorities are still being stood up at the national level in different member states through 2026, and the pace of that rollout isn't uniform. A startup operating across several EU countries should expect some variation in how quickly national authorities begin active enforcement, even though the underlying legal obligations apply consistently across the bloc. That's not a reason to wait for clarity in any one country before starting the audit — it's a reason to treat your compliance posture as something that needs to hold up regardless of which national authority eventually asks about it.
What this kind of work typically costs
Compliance-driven engineering work — the inventory tooling, the architecture cleanup, the disclosure UI, the vendor documentation review — is scoped work with a defined shape, which makes it easier to budget than open-ended legal engagement. Here's how it typically maps to Scult's service tiers:
| Tier | Typical scope for this kind of work |
|---|---|
| Essential ($1,000) | A focused inventory and audit-trail pass on a single app or website: mapping existing AI vendor calls, adding basic logging, and drafting disclosure copy for user-facing AI features. |
| Growth ($2,000) | Architecture cleanup across a multi-service product to centralize AI vendor calls, plus implementing transparency UI and a repeatable documentation process for vendor review. |
| Enterprise ($4,000+) | Full audit-readiness work across web and mobile products, including service-boundary refactoring, ongoing monitoring hooks, and coordination with legal counsel on classification and vendor contracts. |
These are starting reference points based on typical project shapes, not fixed quotes — the right tier depends on how many AI touchpoints your product actually has and how tangled your current architecture is.
How this shows up differently depending on what you're building
Not every startup's exposure looks the same, and it's worth being specific about a few common product shapes.
A consumer mobile app with a chatbot, personalized notifications, and a recommendation feed usually sits mostly in limited-risk territory, meaning the dominant obligation is disclosure. The engineering lift is real but bounded: label the AI interactions, document the vendors, and make sure the disclosure survives a redesign rather than getting quietly dropped six months later when the onboarding flow changes.
A B2B SaaS product selling into regulated industries — finance, healthcare, HR tech — carries meaningfully more exposure, because the decisions those products influence are more likely to fall into high-risk categories. A hiring-adjacent feature that screens or ranks candidates, or a credit-adjacent feature that scores risk, deserves a much more careful classification pass than a general-purpose consumer feature, and probably warrants legal input earlier in the process.
A platform business with a marketplace or user-generated content model often has AI touchpoints in content moderation and ranking that founders don't think to include because they were built as trust-and-safety features rather than "AI features." These belong in the inventory just as much as a customer-facing chatbot does, since automated moderation decisions that affect what users can post or see carry their own transparency and oversight considerations.
Recognizing which of these categories your product falls closest to helps calibrate effort. A consumer app team doing a two-week disclosure and inventory pass and a regulated B2B team investing in a much deeper audit are both being proportionate — the point is matching the depth of the response to the actual risk profile of what you've built, not applying a single template regardless of context.
Key Takeaways
- European startups of every size are now being asked to audit their AI vendor stack for AI Act exposure, a shift that used to apply mainly to large enterprises.
- Start with an inventory of every AI touchpoint in your product, including features you don't think of as "AI-powered."
- Classify each touchpoint against the AI Act's risk tiers before deciding how much engineering or legal effort it deserves.
- Fix architecture gaps that make AI vendor calls hard to trace — clean service boundaries pay off in compliance speed as much as in maintainability.
- Add user-facing disclosure where transparency obligations apply, and treat it as a UI decision, not a legal footnote.
- Assign ongoing ownership of the vendor inventory rather than treating this as a one-time project.
Getting a clear-eyed view of where your product actually stands — before an investor, an enterprise customer, or a regulator asks first — is worth doing deliberately rather than reactively. If you want help mapping your AI vendor footprint and fixing the gaps it turns up, book a meeting with our team.
Frequently Asked Questions
What is an AI vendor compliance audit, exactly?
It's a structured review of every third-party AI system your product relies on, checking what each one does, how it's classified under relevant regulation, and whether the vendor can document that classification. For a startup it usually starts as an internal exercise before any regulator gets involved.
Does the EU AI Act apply to a small startup, or just large companies?
The AI Act's obligations are tied to what a system does and its risk classification, not the size of the company deploying it. A five-person startup using a high-risk AI feature carries the same classification obligations as a large enterprise using the same feature, even if enforcement priorities differ in practice.
My startup just uses AI vendor APIs — do I still have exposure?
Yes. Being a "deployer" of someone else's AI system still carries obligations under the Act, particularly around transparency and, for higher-risk categories, oversight. You can't fully outsource the compliance question to your vendor.
What counts as an "AI feature" for audit purposes?
Anything from an obvious chatbot to a quieter feature like personalized recommendations, automated content moderation, fraud scoring, or smart search. If a model is making or shaping a decision that reaches a user, it belongs in the inventory.
How do I know if my chatbot is "high-risk" under the AI Act?
Most simple customer-support chatbots fall into the limited-risk category, mainly triggering a disclosure obligation. Risk rises sharply if the chatbot makes decisions in regulated areas like credit, employment, or healthcare eligibility — those contexts push toward high-risk regardless of the interface being "just a chatbot."
What's the difference between limited-risk and high-risk AI systems?
Limited-risk systems mainly require transparency — telling users they're interacting with AI. High-risk systems require much more: documented risk management, technical documentation, human oversight mechanisms, and in many cases a formal conformity assessment before deployment.
Can I be penalized if I didn't know my vendor's AI feature was high-risk?
Ignorance of a vendor's classification doesn't remove your own obligations as the deployer. This is exactly why the audit and vendor verification steps matter — you need documented proof of your own diligence, not just good intentions.
How long does a first AI vendor audit typically take for a small team?
For a small product with a handful of AI touchpoints, a disciplined inventory and classification pass can often be completed in one to two weeks of focused effort. The timeline stretches significantly if your architecture makes AI calls hard to trace, or if vendors are slow to produce documentation.
Who on a startup team should own this audit?
Ideally a technical co-founder or lead engineer who can actually trace API calls through the codebase, working alongside whoever handles legal or compliance questions. Treating it as a purely legal task tends to miss the product-level detail that matters most.
Do I need a lawyer to do this audit?
Not for the first pass. You can build the inventory and a rough classification internally. Legal input becomes valuable once you've identified items that plausibly sit in high-risk territory, or when you're finalizing vendor contract language.
What should I ask an AI vendor to prove compliance?
Ask for their own risk classification and reasoning, any technical documentation they can share, their data retention and training practices, whether they rely on subprocessors with their own models, and a contractual commitment to notify you of classification changes.
What if my AI vendor can't or won't provide documentation?
Treat that as a real signal. A vendor unable to explain their own system's risk profile is a weak link in your compliance posture and, separately, a reasonable business risk regardless of regulation.
How does this affect fundraising for European startups?
Investors doing diligence on European startups are increasingly including AI-specific questions in their process, especially for products with consumer-facing or decision-making AI features. A founder with a clean, current inventory answers those questions faster and looks more operationally mature.
Does this affect enterprise sales deals too?
Yes, often more directly than fundraising. European enterprise buyers' procurement and security review processes are starting to include AI vendor questions as standard, meaning your compliance posture can gate deal velocity even before any regulator is involved.
My app has a personalization or recommendation engine — is that covered?
Recommendation and personalization systems generally fall into limited or minimal risk in most consumer contexts, but the details matter — for example, if personalization touches pricing, credit, or employment-adjacent decisions, the classification can shift upward.
What about AI features used only internally, not customer-facing?
Internal-only tools aren't exempt just because users don't see them, especially if they influence decisions that affect people — hiring screening tools are the clearest example. The audit should cover internal tooling, not just the customer-facing product.
How does my app's architecture affect audit difficulty?
If your AI vendor calls are scattered across services without consistent logging or a central integration point, tracing them for an audit takes far longer, and every future audit repeats the pain. Clean, traceable architecture turns a multi-week audit into a multi-day one.
Is this related to accessibility compliance work like WCAG?
They're separate legal requirements, but they demand the same underlying discipline: documenting how your interface behaves for different users, treating compliance as a design constraint, and maintaining that documentation over time rather than doing it once.
What UI changes does AI disclosure actually require?
At minimum, clearly telling users when they're interacting with an AI system rather than a human, in a way that's noticeable rather than buried in terms of service. For generative content, that can mean labeling AI-generated text, images, or recommendations directly in the interface.
Does this apply to mobile apps differently than websites?
The underlying obligations are the same, but mobile apps often have more AI touchpoints than founders realize — push notification personalization, in-app search, image processing, and analytics-driven feature flags can all involve AI vendors that need the same inventory treatment.
What happens if I ignore this and don't audit anything?
At minimum, you're exposed if a regulator, investor, or enterprise customer asks a question you can't answer. At the more serious end, deploying a high-risk AI system without the required documentation and oversight carries real regulatory risk under the Act's enforcement framework.
How often should I redo this audit?
Treat it as a living inventory rather than a single project — update it every time you add or change an AI vendor integration, and do a full review on at least a quarterly cadence if your product ships AI features frequently.
Can I automate parts of this audit process?
Yes, to a degree. Centralized logging and API gateway patterns can automatically flag new AI vendor calls as they're added to your codebase, which turns the "did we add anything new" question into something your monitoring answers rather than something you have to remember to check.
What's the biggest mistake startups make with this audit?
Treating it as a document-writing exercise instead of a codebase-tracing exercise. The real risk usually isn't in what your privacy policy says — it's in AI vendor calls buried in your product that nobody remembered were there.
Should I remove an AI vendor if I can't verify their compliance?
Not necessarily immediately, but it should move up your priority list, especially if the feature touches a regulated decision category. For lower-stakes features, documenting the gap and pursuing better vendor terms is often the proportionate first step.
How does subprocessor risk work with AI vendors?
Many AI vendors rely on other companies' models under the hood — a customer support tool might call a separate model provider you've never directly contracted with. Your inventory needs to trace those subprocessor relationships too, not just your direct vendor list.
What's a realistic budget for this kind of compliance-driven engineering work?
It scales with how many AI touchpoints your product has and how tangled your current architecture is — a single-app inventory and disclosure pass is a much smaller project than a full multi-service architecture cleanup with ongoing monitoring.
Does this create an opportunity to also improve my app's architecture?
Often, yes. Teams that centralize AI vendor calls and add proper logging for compliance reasons typically end up with a more maintainable, easier-to-debug product as a side effect — the same traceability that satisfies an audit also speeds up regular engineering work.
Is there a required disclosure format the AI Act specifies?
The Act specifies the obligation to disclose, not a rigid template — meaning the design of that disclosure is largely up to you, which is exactly why treating it as a UI and copywriting problem produces better outcomes than a generic legal disclaimer.
How do I explain this to a non-technical co-founder or board?
Frame it as risk management with a defined, bounded cost, similar to security or accessibility work: a first inventory pass identifies exposure, and a second phase of targeted fixes closes the highest-priority gaps, without requiring a full product rebuild.
What if my startup operates across multiple EU countries?
More jurisdictions generally means more vendor relationships and more user populations to consider, which increases the size of your inventory but doesn't change the underlying process — inventory, classify, verify, fix, repeat.
Does using a well-known AI vendor (rather than a small one) reduce my risk?
It can reduce documentation risk, since larger vendors are more likely to have already done their own classification work, but it doesn't remove your own obligations as the deployer. You still need your own inventory and disclosure practices regardless of vendor size.
What's the connection between this audit and general data privacy compliance like GDPR?
They overlap significantly — many AI features process personal data, so a GDPR-compliant data flow is often a prerequisite for AI Act compliance on the same feature. Teams that already have solid GDPR practices usually find the AI-specific layer easier to add.
Should this audit happen before or after a product launch?
Ideally before, since retrofitting disclosure and traceability into a shipped product is more expensive than designing it in from the start. For products already live, the audit should happen as soon as possible rather than waiting for a triggering event like a sales deal or investor question.
How does this affect a startup's App Store or Play Store listing?
Neither major app store currently mandates AI Act-specific disclosures directly, but both are tightening their own AI feature disclosure requirements independently, so it's worth treating your in-app disclosure work as covering both regulatory and platform-policy angles at once.
What documentation should I keep after completing an audit?
Keep the inventory itself, your classification reasoning for each item, copies of vendor documentation you collected, and a changelog of when items were added or reclassified. This is the evidence you'd need to show diligence if ever asked.
Is this a one-time cost or an ongoing cost?
Both — there's a larger upfront cost to build the first complete inventory and fix structural gaps, followed by a smaller ongoing cost to keep it current as your product and vendor list evolve.
What if I'm building a new startup from scratch — should I worry about this now?
Yes, and it's cheaper to worry about now than later. Designing your architecture with traceable AI vendor calls and disclosure patterns from day one avoids the more expensive retrofit work that established products are dealing with in 2026.
Does this apply to AI used in my marketing tools, not just my product?
The Act's obligations are broader when AI outputs reach the public in ways that shape decisions or perceptions, so marketing tools using AI-generated content or targeting logic are worth including in your inventory, even if the core obligations there are lighter than in your core product.
How do I prioritize which AI touchpoints to fix first?
Prioritize by two factors: how likely the feature is to be classified as higher-risk, and how customer-facing or decision-critical it is. A feature that's both is worth fixing before a feature that's neither.
What's the risk of over-engineering my compliance response?
Spending disproportionate engineering time rebuilding low-risk features "just in case" burns runway without addressing real exposure. The proportionate response targets actual risk-tier findings, not blanket caution.
Can a compliance audit reveal that I'm using an AI vendor I didn't know about?
Yes, this is common — a feature vendor you contracted with directly may itself be reselling or wrapping another company's model, and that layer often isn't visible until you specifically trace it during an inventory.
How does this intersect with logistics or operational software using AI?
Operational platforms — routing engines, dashboard analytics, automated scheduling — increasingly use AI components too, and the same vendor verification discipline applies whether the AI sits in your customer-facing app or your internal operations tooling.
What's the first deliverable I should expect from a compliance-focused engineering engagement?
A written inventory of AI touchpoints with a rough risk classification for each, plus a prioritized list of architecture and disclosure fixes — this gives you something concrete to act on or hand to legal counsel for review.
Will this audit slow down my product roadmap?
A well-scoped first pass shouldn't derail your roadmap — it's typically a parallel, bounded engineering task rather than a blocking one, unless the audit surfaces a genuinely high-risk feature that needs to pause before further rollout.
How do I handle AI vendors based outside the EU?
Vendor location doesn't remove your obligations as an EU-based deployer serving EU users — the inventory and verification steps apply the same way regardless of where the underlying vendor is headquartered.
What's a good sign that my current architecture will make this audit hard?
If you can't answer "which services call which AI vendors" without grepping through code for twenty minutes, that's a sign your architecture needs the traceability work described in this guide.
Should this audit be part of my due diligence process when evaluating new AI vendors going forward?
Yes — the most efficient way to avoid a painful catch-up audit later is to fold vendor classification and documentation checks into your normal vendor evaluation process going forward, rather than treating compliance as a retrospective exercise.
How specific does my AI vendor inventory need to be?
Specific enough that someone unfamiliar with your codebase could read it and understand what each AI feature does, which vendor provides it, and what risk tier it falls into — a vague list of vendor names without functional detail isn't useful in an actual review.
What's the realistic timeline to become "audit-ready" from a standing start?
For a small to mid-sized product, a focused four-to-eight week engagement covering inventory, architecture fixes, and disclosure work is a realistic timeline to reach a defensible baseline, with ongoing maintenance after that.
