The questions people actually ask us.

Cost varies by scope (a single web app vs. a full network vs. a whole organization) and depth (black-box vs. white-box) — from a focused few-day engagement to a multi-week assessment for larger environments. Get a scoped quote rather than relying on a generic number.

Yes. Automated scanning catches known, signature-based issues; a VAPT adds human-led, context-aware exploitation attempts — including business-logic flaws — that scanners can't replicate.

At least annually for most organizations, plus after any significant infrastructure or application change, and increasingly paired with continuous, lighter-touch testing in between.

No. Insurers increasingly require evidence of baseline controls — MFA, patching, backups, incident response — before binding a policy or paying out a claim, so insurance supplements a security programme rather than replacing one.

Yes. Even a small environment typically runs more service accounts, API keys and automation scripts than human users, and these are often the least monitored, most over-privileged accounts in the environment.

Start with a lightweight gap assessment against a recognized framework, such as CIS Controls or NIST CSF, to find the highest-risk gaps — rather than jumping straight to a full VAPT or certification effort.

A penetration test targets a defined scope — an app, a network segment — to find and demonstrate as many exploitable flaws as practical within a set timeframe. A red team exercise simulates a realistic adversary pursuing a specific objective (like reaching sensitive data) stealthily, testing detection and response as much as the technical defenses themselves.

Not immediately, but every finding needs a documented decision — fix, accept the risk, or compensate with another control. Unaddressed low-severity findings are a common audit red flag precisely because "we'll get to it" so often means "we never did."

No. A WAF blocks known attack patterns at the network edge, but it doesn't fix the underlying vulnerable code, and sophisticated or novel attacks can bypass it entirely. It's a useful compensating control, not a substitute for secure development and testing.

Grey-box (testers get some internal context, like a standard user account) usually gives the best balance of realism and depth for most organizations. Pure black-box is more realistic but can burn engagement time on reconnaissance; white-box (full source/architecture access) is best for deep assessments of a specific high-risk system.

Most mature programmes target critical, actively-exploited vulnerabilities within 24–72 hours and other critical findings within 2 weeks, with longer windows for high/medium severity — but the number matters less than having a documented SLA at all and tracking adherence to it.

Most small and mid-size organizations are better served by an MDR/SOC-as-a-service provider — 24/7 in-house monitoring is expensive to staff well. Build an internal SOC only once scale and risk genuinely justify the dedicated headcount.

Costs span three buckets: internal implementation effort, any external consulting support, and the certification body's audit fees. They scale with organization size and scope — most mid-size organizations should budget several months of dedicated effort alongside the direct audit fees.

Yes, if you already have an experienced internal owner and reasonable security maturity. Many organizations do succeed alone, but most find a consultant pays for itself by avoiding costly mistakes in scoping and the Statement of Applicability.

A major nonconformity pauses certification until it's corrected and verified, usually requiring a follow-up audit. A minor nonconformity typically just needs a documented corrective action plan before certification is issued.

No. ISO certification is valid for three years, with shorter annual or 18-month surveillance audits in between to confirm the management system is still being maintained.

Yes. ISO 27701 is explicitly designed as an extension to an existing ISO 27001 ISMS, though it can now also be certified standalone — organizations commonly run them as one integrated management system rather than two parallel efforts.

Many organizations start with whichever their most important customers or market demands first, then add the other as their customer base diversifies. Holding both isn't unusual for companies selling into both US and international enterprise markets.

The 2022 revision restructured Annex A from 114 controls across 14 domains into 93 controls across 4 themed groups, and added new controls reflecting modern risk — cloud security, threat intelligence, data masking and secure coding among them. Organizations certified under the old version have a transition deadline to migrate.

Stage 1 is a documentation review — the auditor checks your ISMS scope, policies and Statement of Applicability are complete and ready for assessment. Stage 2 is the real test: the auditor checks for actual operating evidence that the controls you documented are genuinely being followed.

Yes — company size doesn't determine certifiability, scope and risk do. Small teams often move faster precisely because there's less legacy process to untangle, though they do need to resource the effort seriously rather than treat it as a side project.

A nonconformity means a control isn't operating as required — major ones block certification until fixed and verified, minor ones need a corrective action plan. An observation flags something that isn't a current failure but could become one, and doesn't block certification, though ignoring it repeatedly often turns it into a future nonconformity.

No, but it helps substantially. ISO 27001 builds the security backbone — risk management, access control, incident response — that privacy regulations assume exists, but DPDPA/GDPR add their own distinct requirements around consent, data subject rights and lawful basis that ISO 27001 doesn't cover on its own.

Type I confirms your controls are designed correctly at a single point in time; Type II confirms they actually operated effectively over a review period, typically 6–12 months. Most enterprise buyers specifically ask for Type II because it's real evidence of sustained practice, not just a documented design.

Yes, if you offer goods or services to individuals in India and process their digital personal data in that context. DPDPA has extraterritorial reach similar to GDPR's, though specifics should be confirmed with counsel for your situation.

DPDPA sets financial penalties that scale with the nature and severity of the breach, decided by the Data Protection Board case by case — there isn't a single fixed number, which is part of why documented, demonstrable compliance effort matters even before any incident occurs.

Not necessarily both. A DPO is only mandatory if you're designated a Significant Data Fiduciary; a Consent Manager is a separate, optional entity individuals can choose to manage their consents through, not something every organization needs to appoint itself.

Timelines vary widely based on how much of a data inventory, consent infrastructure and security baseline already exists. Organizations starting from nothing should budget several months for a genuine first pass, not weeks.

No. Once data is genuinely and irreversibly anonymized so it can never be linked back to an individual, it falls outside DPDPA's scope. Pseudonymized data, which can still be re-identified, remains regulated.

Start with a data mapping exercise — you can't assess risk, write accurate notices, or respond to a rights request for data you haven't inventoried.

Generally yes — DPDPA requires consent to be specific and granular, not one broad blanket acceptance covering unrelated purposes. Bundling marketing consent with, say, account-creation consent is a common compliance gap.

Before any processing activity that's likely to pose a significant risk to individuals — large-scale sensitive data processing, new tracking technology, profiling with legal or similar effects. Doing it before launch, not after, is what makes it useful.

DPDPA takes a more permissive approach than GDPR — cross-border transfer is generally allowed except to countries the government specifically restricts, rather than requiring a transfer mechanism for every destination. Confirm current restricted-country status with counsel, since this list can change.

It covers employees too, with a narrow carve-out for processing necessary for employment purposes like safety and HR administration. Marketing-style processing of employee data still needs a proper lawful basis.

DPDPA is lighter on prescriptive mechanism (no formal "legitimate interest" balancing test, fewer mandated documents) but sets potentially very large penalties and gives individuals clear rights to access, correct and erase data — the practical compliance work of mapping data and honoring rights requests looks similar either way.

Organizations must notify the Data Protection Board and affected individuals, though exact timelines are still being finalized in implementing rules — the safe practice is to treat it like GDPR's 72-hour standard until the rules confirm otherwise, since being ready for the stricter timeline costs little extra.

It depends on jurisdiction and sector. WCAG itself is a technical standard, not a law, but it's referenced by binding regulations like the European Accessibility Act and Section 508, and increasingly by ADA case law — so treating it as optional carries real legal risk in many markets.

Cost scales with product size and testing depth — a lightweight automated-plus-spot-check review costs far less than a comprehensive manual audit with real assistive-technology and screen-reader testing across every key flow.

No. Overlays are widely found not to achieve real WCAG conformance, since they can't fix underlying markup, keyboard operability or structural issues, and several have themselves faced accessibility-related lawsuits.

Automated tools catch roughly a third of WCAG issues at most. Manual testing, and ideally real assistive-technology users, are needed to catch the rest, especially around usability and cognitive accessibility.

Fix the highest-impact, most commonly litigated issues first — missing alt text, keyboard traps, insufficient color contrast — while scoping a full audit, rather than waiting for a comprehensive fix before addressing anything.

It adds the most friction when retrofitted late. Built into design systems and component libraries from the start, accessible patterns become the default and cost little to no extra time per feature.

AA is the standard target referenced by almost every regulation and procurement requirement worldwide, including the European Accessibility Act. AAA is rarely required in full and some of its criteria are genuinely impractical for certain content types — aim for AA, with select AAA criteria where they're a natural fit.

No. The European Accessibility Act extends requirements to private-sector e-commerce, banking and other consumer-facing digital services, and ADA litigation in the US has overwhelmingly targeted private companies, not government sites.

Yes, in substance. WCAG was written with web content in mind, but its principles map directly onto mobile platform accessibility guidelines (Apple's and Android's), and VPATs and audits routinely cover native apps against the same success criteria.

An audit is the testing process that finds and documents actual conformance issues. A VPAT (Voluntary Product Accessibility Template) is a standardized document — often requested by enterprise and government procurement — that reports conformance status per criterion, ideally backed by that audit's real findings.

For simple, literal images it's a reasonable starting draft, but AI alt text regularly misses context that matters — what the image means in that specific page's purpose — and can be confidently wrong. Treat it as a first pass a human reviews, not a final answer.

Overlays operate client-side and can't repair the underlying HTML, keyboard traps or missing semantic structure that cause most real accessibility failures — and several overlay vendors have themselves been named in accessibility lawsuits for exactly that gap between marketing and reality.

Not strictly required by law in most jurisdictions today, but it's becoming a meaningful trust signal for enterprise customers and procurement teams — similar to the role ISO 27001 plays for security.

Start narrow — scope autonomous action to low-consequence, easily reversible tasks, and require human approval for anything high-consequence or hard to reverse, expanding autonomy only as the agent proves reliable.

It's a real, demonstrated risk, especially for agents that retrieve content from the web, documents or tool outputs — any untrusted content an agent reads is a potential injection vector, not just the user's direct prompt.

They reduce integration risk and vendor lock-in by standardizing how agents connect to tools, but they don't eliminate the need for your own guardrails, permissioning and monitoring around what an agent is allowed to do with that access.

RAG is usually the faster, cheaper starting point for grounding a model in your own data and is easier to keep current. Fine-tuning suits teaching a model a specific style, format or specialized skill that retrieval alone can't achieve.

Potentially yes — like GDPR, the EU AI Act has extraterritorial reach for AI systems whose output is used within the EU, regardless of where the provider is based.

No, not with current generative architectures — it can be substantially reduced through grounding (RAG), guardrails and verification layers, but treat "zero hallucination" as a marketing claim to be skeptical of, not an achievable engineering target.

A chatbot responds to messages within a conversation. An agent additionally plans, calls tools or APIs, and takes multi-step actions toward a goal with limited supervision — the distinction that matters for risk is autonomy and the ability to act on the world, not just converse about it.

APIs are faster to start with and offload infrastructure and model-upkeep burden; self-hosting an open-weight model gives more control over data residency, cost at scale and customization. Most organizations start with an API and only self-host once a specific requirement — cost at volume, strict data residency — justifies the added operational burden.

Employees using unapproved consumer AI tools — pasting customer data into a public chatbot, for instance — outside any governance or security review. It's increasingly one of the most common sources of unintentional data exposure, precisely because it happens informally and goes unmonitored.

Increasingly yes, depending on jurisdiction and context — several emerging regulations (including provisions of the EU AI Act) require disclosure for certain AI-generated content, and customer trust considerations argue for transparency even where it isn't yet strictly mandated.

Enough that it's become its own category of financial risk — token costs scale with usage in ways that are easy to lose track of, especially with agents that make multiple model calls per task or get stuck in retry loops.

Regular software testing checks deterministic pass/fail behavior; LLM applications produce probabilistic, varying outputs, so evaluation relies on quality metrics and scoring rubrics rather than simple equality checks.

No. Most mature pipelines use automated metrics and LLM-as-a-judge scoring for scale, reserving human review for periodic spot-checks and safety-critical categories where automated scoring alone isn't trustworthy enough.

Continuously, ideally. An automated evaluation pipeline should re-run whenever the model, prompts or underlying data change, since any of those can silently degrade quality without a visible error.

There's no universal number — it depends heavily on use-case risk — but it should be measured against a defined baseline and tracked over time, not left unmeasured until a customer notices.

With care. LLM-as-a-judge scales evaluation well but carries its own biases and blind spots, so it's best combined with periodic human review, especially for safety or compliance-sensitive outputs.

Many organizations start with a lightweight internal pipeline using open-source evaluation libraries, then move to a dedicated platform once evaluation needs to run continuously across multiple models, prompts and release cycles.

Unit tests check deterministic, known-correct outputs for fixed inputs. Evaluation scores quality across a representative distribution of inputs using rubrics and metrics, because the same prompt can legitimately produce different acceptable outputs each run — there often isn't one "correct" answer to assert against.

Groundedness (does the answer stick to what the retrieved context actually says), retrieval relevance (did it fetch the right documents at all), and answer relevance to the question — measuring only final-answer quality without these hides whether failures come from retrieval or generation.

Curate a representative set of real or realistic inputs — including edge cases and known-hard examples — paired with expert-approved expected outputs or scoring rubrics, then version it so every future evaluation run compares against the same fixed baseline.

Judge models can show systematic biases — favoring longer answers, being lenient toward outputs in a style similar to their own training, or missing subtle factual errors a domain expert would catch — so periodic human review stays necessary even in an LLM-judged pipeline.

Run your evaluation suite on a schedule against a fixed baseline, and flag any unexpected score movement — a quietly-upgraded underlying model can change behavior on your specific use case without any announcement from the vendor.

Yes. Quality metrics (helpfulness, accuracy, relevance) and safety metrics (harmful content, policy violations, jailbreak resistance) can move independently, and optimizing purely for quality has been shown to sometimes quietly erode safety behavior.

Automate the stable, repetitive checks — regression, smoke tests — to free up time for manual and exploratory testing on new, complex or high-risk features, where human judgment catches more than a script will.

There's no universal target. High coverage on trivial code is less valuable than solid coverage on your highest-risk, most frequently changed logic — track coverage as a signal, not a goal in itself.

This usually means tests are tied too tightly to brittle locators, like exact pixel positions or auto-generated IDs. More resilient locator strategies, or self-healing test automation, reduce this maintenance burden significantly.

No. Scale the depth of non-functional testing to the risk of the release — a small config change doesn't need a full load test, but anything touching authentication, payments or core infrastructure should.

It shows up over time, not immediately. Automation has an upfront build cost, but pays off through faster regression cycles, fewer production defects, and freeing testers for exploratory and high-value testing.

Prioritize by actual usage data from your analytics rather than testing every theoretical combination, and use cloud-based device/browser testing grids to cover the long tail efficiently.

Shift-left moves testing earlier — into design and development, before code reaches QA — to catch defects cheaply. Shift-right tests in or close to production — canary releases, synthetic monitoring, feature flags — to catch what only shows up under real traffic and data. Mature programmes do both, not one instead of the other.

Developers should own unit and component-level tests close to their code; QA should own integration, end-to-end and exploratory testing where a broader, user-facing view matters more. Splitting it this way catches more than either group working in isolation.

Contract testing verifies that a service's API still meets the expectations its consumers rely on, independent of a full end-to-end test. It becomes valuable once you have multiple services or teams integrating via APIs — it catches breaking changes at the source, before they cascade downstream.

It meaningfully reduces maintenance from routine UI changes by automatically adapting locators, but it isn't infallible — it can occasionally "heal" a test past what should have been a genuine failure, so treat its changes as something to spot-check periodically, not something to fully automate out of review.

The classic "testing pyramid" — many fast unit tests, fewer integration tests, a lean set of end-to-end tests — still holds up well: end-to-end tests are the most realistic but also the slowest and most brittle, so they should cover critical paths, not every scenario.

For any product with frequent UI changes, automated visual regression (pixel/DOM diffing against a baseline) catches unintended changes far more reliably and cheaply than manual eyeballing, especially across many screen sizes and themes.

When a monolith's size is genuinely slowing teams down — deployment bottlenecks, being forced to scale the whole system to scale one part, team coordination overhead — not simply because microservices are currently fashionable. The added operational complexity isn't free.

Frame it around the business cost of not modernizing — rising maintenance cost, slower time-to-market, security and compliance risk, and the growing difficulty of hiring for an aging stack — rather than purely technical merits.

You can start smaller. Even a lightweight current-state/target-state exercise for your highest-priority domain delivers real value before investing in a full EA practice and tooling.

Only if it's solving a specific need — resilience, a regulatory requirement, or avoiding vendor lock-in for a critical capability. Adopted without a clear reason, multi-cloud usually just adds operational cost without a matching benefit.

Give engineering and product teams visibility into what their own usage actually costs — a FinOps practice — rather than leaving cost management solely to finance after the bill arrives.

Underestimating the undocumented business logic buried in the legacy system. "Big bang" rewrites that don't account for it tend to fail; an incremental, strangler-pattern approach that migrates piece by piece is usually lower-risk.

Enterprise architecture looks across the whole organization — how business capabilities, data and systems fit together strategically. Solution architecture designs a single system or project within that broader context. Most organizations need solution-level discipline well before they need a dedicated EA practice.

Build when the capability is close to your actual competitive differentiation and you need control over its roadmap; buy when it's a commodity function (auth, payments, email) where a mature vendor will out-invest what you could justify building and maintaining yourselves.

Most organizations benefit from TOGAF's concepts — current-state/target-state mapping, architecture decision records, governance gates — without adopting the full formal process. Treat it as a toolbox to borrow from, not a certification to chase for its own sake.

Plan for AI agents as a new category of system consumer — they need their own authentication, rate limits, auditable action boundaries and monitoring, distinct from how you've architected for human users and traditional service-to-service calls.

DevOps is a practice — shared responsibility for build, deploy and operate across dev and ops. Platform engineering is a dedicated team that builds internal tooling and self-service infrastructure so other teams can practice DevOps effectively without each reinventing it.

Replace when the platform itself is the constraint — it can't be scaled, secured or integrated no matter how much you invest. Modernize incrementally when the core platform is sound but specific components or practices around it have fallen behind.