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?

Beginner friendly checklist? You're overcomplicating it. Stop asking for generic steps and check the audit log for "evaluated: 0 resources." That's likely your issue.

The update probably broke your resource mapping. Run this and compare the output to your policy's resource filter.

```
config where cloud.service = 'S3'
```

If that shows buckets but your check shows zero, your query is dead. It's a syntax or alias problem, not an activation step. Just fix the query.

Oh, thanks for that checklist in your last paragraph. Starting with the audit log for "evaluated: 0" sounds like the right move. I'm in a similar spot trying to learn this.

When you run that inventory check `config where cloud.service = 'S3'`, what if it shows your buckets but they have a different naming format now? Does that mean you have to rewrite the whole custom check, or is there a way to just update the resource filter?

To answer your specific question about resource naming: if the inventory query shows buckets but with a different naming format or identifier than your policy expects, you do not necessarily need to rewrite the entire check. You only need to update the resource filter clause, typically the `resourceType` or `cloud.service` condition, to match the new internal mapping. However, I strongly recommend cloning the policy rule and creating a new one after making the correction. My own benchmarks show that merely editing an existing, orphaned rule can leave stale metadata cached in the evaluation engine for up to 72 hours, while a newly created rule activates within the next scan cycle.

For a step-by-step approach, start with the inventory query `config where cloud.service = 'S3'` to confirm the assets are visible. Then, run a targeted query using the exact `resourceType` string from your custom policy. If the first query returns data but the second does not, you've isolated the alias change mentioned by user1454. Update the filter in a cloned policy.

Regarding community resources, the unofficial PCQL GitHub repository maintained by the community often documents these mapping changes faster than the official release notes. I'd cross-reference there.

Great checklist start, but I'd nudge you on one thing: the audit log is actually step two. Always start with the inventory. Otherwise you're debugging a ghost.

Run this first, before you even touch the logs:

```
config where cloud.service = 'S3' and bucketEncryptionRule is null
```

If that *does* return unencrypted buckets but your custom check doesn't, then your query's asset mapping is broken (probably the `resourceType` alias issue people mentioned). If that query returns *nothing*, then your problem is elsewhere, like a credential/permission scope that got reset by the update.

Also, never just "edit" a broken custom check post-update. Clone it, create a new one with the corrected query, and disable the old one. The cache lag on edited policies is real, and you'll waste days waiting for it to self-heal.

No. The audit log first is still wrong. You're checking for symptoms before confirming the disease exists.

If the inventory query shows a different format, you just update the filter, usually the resourceType line. But editing is pointless, the cache is junk for days. Clone a new rule.

And don't trust the naming format you see, they change it every other update to keep us annoyed.

That's a really interesting point about WHERE clause order. I've observed similar behavior, but more related to performance degradation than total failure. The evaluation engine's query planner sometimes struggles with predicate pushdown after metadata schema updates.

For your Azure storage example, the service name shift often correlates with a provider API version bump in the platform backend. The alias gets remapped, but the old logical reference in saved queries becomes a dead pointer. In those cases, even re-ordering clauses won't help; you need to find the new canonical service name from the updated resource schema documentation.