Settings

Settings holds the two pieces of tenant-wide configuration in Cloud Posture today: which resource tag keys are mandatory, and who gets notified about scans and findings, and how.

What’s on the page

Settings opens straight into Required tags, with Notifications as a second section in the same left-hand sub-navigation.

• Required tags:a text field to add a tag key, and a list of removable chips for the keys you’ve already added. A Save changes button shows an “unsaved changes” indicator once you’ve edited the list.
• Notifications:a table of event types with their recipients (default team recipients, or an explicit list) and delivery mode (Immediate, or a digest — with a “Locked: always Immediate” pill on events that can’t be delayed). A separate section lists any recipient addresses that have started bouncing and been suppressed.

What you can do

Add, remove or save required tag keys

Owner, Admin or Engineer. Other roles see the same list, read only, with a note explaining who can change it.

Edit a notification event’s recipients or delivery mode

Owner, Admin or Engineer, via an edit dialog offering default vs. explicit recipients and Immediate vs. digest delivery — locked to Immediate for events that must stay that way.

How to read it

• A missing required tag produces an ordinary low-severity finding, the same as any other check — it’s never a hard block and never fails a scan outright.
• There’s no grace period. Enforcement applies from the very next scan after you save the policy — there’s no warning-only window.
• Changing the required-tags list only affects the next scan. It never retroactively changes findings from scans that already ran.
• With no keys configured at all, the required-tags checks stay completely dormant — that’s not the same as every resource passing, it simply means nothing is being evaluated.
• Tag-key matching is exact and case-sensitive. Keys are limited to 128 characters, up to 50 per tenant, and the reserved aws: prefix is rejected.
• Clearing the entire required-tags list needs an extra confirmation step, specifically because it turns those checks off for everyone until keys are added back.
• One notification event — the record of suppressed recipient addresses itself — is system-managed and isn’t editable from this table.
• Critical findings always notify immediately and can’t be moved to a digest, in the interface or on the server.
• Saving either settings page carries the version you last loaded; a conflicting change elsewhere shows a message asking you to refresh rather than being silently overwritten.

Before your first scan

A brand-new tenant starts with no required tag keys configured — “Required-tags checks stay dormant until keys are added.” The notifications table is never empty: the fixed set of event types is always listed, scan history or not. The suppressed -addresses section reads “No recipient addresses are currently suppressed” until one actually bounces.