Wiz vs Orca POC: 30 questions to ask in any CNAPP trial

A cloud security proof of concept usually ends with two vendors who both found plenty, both demoed well, and a team that still cannot say which one to buy. That is not the buyer's fault. Point any CNAPP at a messy cloud account and findings appear. The questions below are designed to separate platforms that look identical in a demo, whether your shortlist is Wiz vs Orca, Wiz vs Cortex Cloud, or anything else.

They are vendor-neutral on purpose. Onam Security wrote this, and Onam sells a cloud security platform, so where we mention ourselves it is labelled. Every question works just as well with us left off your list.

Before the POC: set it up so the answers mean something

Most POCs are decided before the first scan, by how they are set up.

• Use the same accounts for every vendor. Two or three non-production accounts you know have real problems, connected to every platform in the same week. Different accounts produce incomparable results.
• Plant known issues. Before connecting anyone, create five to ten misconfigurations you can name: a public storage bucket, a role with a wildcard policy, a security group open to the internet, an unencrypted database, a workload with a known vulnerable package and a path from it to sensitive data. You now have an answer key.
• Write the success criteria down first. Three to five outcomes, agreed with whoever signs the purchase, before any vendor is in the room.
• Name one scorer per criterion, so the platform with the best sales engineer does not win by default.

Two weeks is enough for everything below. A POC that needs longer is usually missing an answer key.

Week 1, days 1–2: access and deployment

1. Exactly what permissions does onboarding grant? Ask for the policy or template before you run it, and read every action. Read-only should mean read-only.
2. What runs in my account, and who pays for it? Some scanning creates resources in your account, such as snapshots or scanner compute. Ask what, where, and whether it shows on your cloud bill.
3. Which features need an agent or sensor, and on which workloads? Both Wiz and Orca describe agentless scanning plus an optional runtime sensor on their own pages, so ask both precisely what the sensor adds and what a workload without it receives.
4. Where does my data go? Which region stores findings and metadata, what leaves the account, and how long it is retained.
5. How long until the inventory is complete? Do not ask, measure. Note when each account was connected and when its inventory stopped growing.

Week 1, days 2–4: coverage

1. Which of my clouds get the full engine? Ask for the per-cloud rule breakdown, not the headline total, and a live demo on your second and third clouds, not only AWS.
2. Which of my services are covered? Export the inventory and compare it with your own list of services in use. The missing ones matter more than the count.
3. How is Kubernetes covered? Cluster configuration, workload configuration, RBAC, and whether a container finding links to the cloud identity the pod can assume. See KSPM.
4. What about identity? Effective permissions, unused permissions, and cross-account trust. Ask on which clouds each of those works. See CIEM.
5. Does it see code and infrastructure as code? And can it trace a runtime finding back to the Terraform or template that created it, so the fix is not undone on the next deploy?

Week 1, day 5: accuracy

1. Did it find every planted issue? Score against your answer key. This is the single most objective test in the POC.
2. How many of the top 50 findings are real? Have an engineer mark each as real, false positive, or accepted risk. Compare the false-positive rate across vendors.
3. How many findings are the same problem counted twice? One public bucket can surface as a posture finding, a data finding and an exposure finding. Duplicates inflate counts and waste triage time.
4. How fast does a change show up? Make a configuration change and time how long until it appears as a finding, and how long until it closes after you fix it.
5. How are exceptions handled? Can you accept a risk with an owner, a reason and an expiry date, and does it come back when it expires?

Week 2, days 1–2: prioritisation

1. What does it rank first, and why? Ask the vendor to explain the top three findings in your accounts, live, without slides.
2. What unit is the ranking in? A severity label, a score, or business impact? Ask how you would explain the number to a CFO. See cloud risk quantification.
3. Does it connect findings across engines? A public subnet, an over-privileged role and a vulnerable workload are each medium alone and serious together. Ask it to show that chain in your accounts. See cloud attack paths.
4. Can an attack path cross a cloud boundary? If you run more than one cloud, ask whether federation between them is modelled, and demo it.
5. How are vulnerabilities weighted? CVSS alone, or exploit likelihood such as EPSS and known-exploited status, and reachability? See EPSS over CVSS.

Week 2, days 3–4: remediation and workflow

1. What does the fix guidance look like? Console steps, CLI, and an infrastructure-as-code change. The IaC fix is the one that lasts.
2. Does it route findings to the right owner? By account, tag or team, into the ticketing tool you already use, without opening one ticket per duplicate.
3. If it auto-remediates, with what permissions? Any write access is a new attack surface. Ask what it can change, who approves, and how it is audited.
4. Does a fix get verified? The finding should close on the next scan, with evidence, not when someone ticks a box.
5. Can each team see only its own estate? Role-based access, scoped views, and SSO with group mapping.

Week 2, day 5: compliance, cost and exit

1. Which frameworks are mapped, and is evidence continuous? Ask whether framework scores update as infrastructure changes or only when a report is exported.
2. What does an auditor actually receive? Export a report for one framework and ask your auditor whether it is usable.
3. What unit does the price grow with? Workloads, resources, accounts or spend, and what happens to the bill when your estate doubles.
4. What is in the base package and what is an add-on? Get it in writing against the features you used in the POC.
5. How do I get my data out? API access, bulk export, and what happens to your data when the contract ends.

A scoring sheet you can copy

Change the weights to match your success criteria, but fix them before the POC starts, not after you have a favourite.

Wiz vs Orca specifically

Both vendors describe a similar shape on their own pages. Wiz says it "connects in minutes via API" with "Runtime protection from the Wiz Sensor" (wiz.io/platform, 7 October 2026). Orca describes "Agentless scanning across every workload" through SideScanning and "Runtime observability & protection" from the Orca Sensor (orca.security/platform, 7 October 2026). Because the architectures are close, the differences will show up in questions 11 to 20: what each finds in your accounts, how much is noise, and what each ranks first. That is where to spend your scoring time. For more options beyond these two, see Wiz alternatives in 2026 and the best CSPM tools.

Warning signs during a POC

None of these proves a product is wrong for you, but each deserves a direct question.

• The demo only ever runs in the vendor's own tenant, never yours.
• The top findings are generic benchmark checks with no context about your environment.
• Rule counts are given as one total with no per-cloud breakdown.
• Nobody can explain, live, why the first finding is ranked first.
• Pricing arrives only after the POC is "won".

Where Onam fits (our section)

If you include us, these are our answers, stated so you can check them. Posture scanning connects through read-only cloud roles you can read before you run them; workload scanning runs inside your account, and there is no Onam sensor on your hosts. Posture rules cover seven clouds, including OCI, Alibaba Cloud and IBM Cloud, and we publish the per-cloud counts. Findings sit on one graph, so a path can cross clouds, and each finding carries a FAIR-style loss estimate with its inputs shown. Compliance is recomputed on every scan against 78 frameworks.

The honest limit: we have no public reference customers yet and no runtime enforcement. If inline blocking is one of your success criteria, we will not meet it. Our answers to the seven questions that matter most are in Wiz vs Orca vs Prisma Cloud: 7 questions that decide a POC, and the head-to-heads are on the Onam vs Wiz and Onam vs Orca pages.

Frequently asked questions

What questions should I ask during a Wiz vs Orca POC?

Ask what onboarding grants, what the runtime sensor adds, whether each platform found your planted issues, its false-positive rate in the top 50 findings, what it ranks first and why, how it routes and verifies fixes, and what unit the price grows with. The 30 questions above cover each week of a two-week POC.

How long should a CNAPP POC take?

Two weeks is enough if you prepare an answer key of planted issues and agreed success criteria before the first vendor connects. Longer POCs usually signal unclear criteria rather than a harder evaluation.

How many vendors should be in a POC?

Two or three, including your incumbent if you have one. More than three in the same accounts and the same fortnight is hard for one team to score fairly.

Should a POC use production accounts?

Start with non-production accounts that mirror production and contain known issues. Add a production account only once the permission review in question 1 is complete and signed off.

What success criteria should a cloud security POC have?

Three to five measurable outcomes agreed before it starts, for example: finds all planted issues, false-positive rate below an agreed level in the top 50, top three findings explained live, and a fix verified automatically on rescan.

Read next: What is CNAPP, What is CSPM, and how attack paths work.