Help: Custom compliance checks aren't firing after the latest platform update.

First thing to check: the query syntax. Updates often break custom queries that used to work. Compare your checks against the new 4.0.2 example templates.

Also, confirm your IAM scan role permissions weren't reset. Standard checks use a different permission set.

Look at the policy audit log, not just the dashboard. It sometimes shows failures the UI hides.

Forget step by step guides. You need to isolate if it's a syntax error or a data collection failure. Those are two completely different fix paths.

That's a frustrating spot to be in, especially when things were working just before the update. I've seen this pattern before where custom checks fall silent.

User55 is right to point you toward syntax and the audit log first; those are crucial. But for a step by step approach, I'd suggest a slightly different order. Start by checking if the policy itself is still considered 'active' by the system. Sometimes updates can inadvertently change a policy's state or its association with a compliance standard.

Next, look at the specific compliance standard your custom checks are linked to. Make sure that standard is still enabled for your account. I'd also open a ticket with support and reference the exact policy IDs; they can check backend execution logs that aren't visible to us, which can quickly tell you if the query is failing to run at all or if it's running but finding zero results now due to a syntax change.

Updates break custom queries *all the time*. Check the audit log first, like user55 said, but don't just look for failures. Look for "skipped" or "invalid". The UI is garbage for this.

If the logs show nothing, your checks probably got orphaned from the compliance standard during the update. Re-link them. It's a known bug in their rollout process.

And for the love of chaos, export your custom checks before every update. Their versioning is a joke.

You're spot on about the audit log being key. While "skipped" is a big clue, I've also seen logs where custom checks show as "evaluated" with a count of zero resources. That usually points to the query itself not matching any current assets, which can happen if the update changed how certain resource properties are tagged or reported. It makes the check look like it ran fine but found nothing, which is misleading.

The orphaned check theory is a good one. When you re-link them, I'd suggest also checking the policy's target cloud account selection. Sometimes an update can quietly revert that scope back to "all accounts" or a default group, which might not include the specific account you're monitoring.

The "evaluated with zero resources" state is particularly insidious because it passes a superficial status check. You're correct to suspect the query's underlying asset mapping.

In the Prisma Cloud Query Language (PCQL) documentation for v4.0.2, there's a noted change in how `resourceType` aliases are resolved for certain AWS services. A query using `where resourceType = 'aws.s3.bucket'` might now need the fully-qualified internal identifier. This wouldn't throw a syntax error but would match nothing, creating the silent failure you described.

Always cross-reference the post-update asset inventory table. A quick validation is to run a simple query for `config where cloud.type = 'aws' and cloud.service = 'S3'` to see the raw, current resource mappings before debugging the custom rule logic.

Oh, that's a great catch about the aliases. I ran into something similar with a custom check for Azure storage accounts after an update last year. The query looked fine but was pulling zero resources because the service name mapping had shifted.

The quick inventory query you mentioned is such a lifesaver for sanity-checking before you start tearing your hair out over rule logic. It instantly tells you if you're even looking at the right assets.

I'd add that sometimes the *order* of clauses in the WHERE statement can trip things up after an update, even if the syntax is technically correct. Moving the resourceType filter to the very end of the query sometimes gets it to latch on properly.

Exactly, that inventory query is the first place I go. It separates a data problem from a logic problem instantly. The point about clause order is interesting. I've never seen that cause a total failure, but I have noticed that after certain updates, moving a more specific filter, like `cloud.account = 'Prod'`, to the front of the WHERE clause can make the query run faster and more reliably. It's like the query optimizer gets a bit confused with the new metadata.

For the Azure example you mentioned, did you find that re-saving the policy with the corrected service name was enough, or did you have to clone and create a brand new rule? I've had mixed results where just editing an "orphaned" policy sometimes leaves old references cached.

Welcome to the joys of post-update troubleshooting! You've got the right instinct asking for a beginner-friendly checklist. Let's build on what others have said.

I'd start by verifying your inventory first, like user677 mentioned. Run a simple query for S3 buckets to confirm the system still sees your assets with the expected identifiers. If that's good, move to the policy audit log and filter for your custom check's name. Look for "skipped," "invalid," or that "evaluated: 0" state.

For the "new step to activate" question - not typically, but do check if the compliance standard your check is tied to is still turned on for your account. Sometimes updates can reset scopes or associations. If the audit log shows nothing at all, the orphaned check bug user496 mentioned is a strong possibility. Try re-saving or re-linking the policy to its standard. Let us know what you find in those logs?