Risk Acceptance – Accept AWS Findings with Audit Trail

Not every security finding can or should be fixed immediately. Sometimes a finding affects a resource that’s being decommissioned next quarter, or your team has reviewed it and decided the risk is acceptable given your threat model. Risk acceptance lets you record that decision formally — with a reason, an owner, and an optional expiry — so it doesn’t get lost in a spreadsheet.

What happens when you accept a risk

The finding moves to accepted lifecycle state and is filtered out of your active findings view
The acceptance is stored with your reason, the accepting user, and the timestamp
If you set an expiry date, TroveSec automatically revokes the acceptance on that date — the finding returns to active on the next scan
The full acceptance history is preserved for audit purposes

Risk acceptance does not change anything in your AWS account. It only records your decision in TroveSec.

Accepting a risk via Claude

Tell Claude which finding you want to accept and why. Claude will call accept_risk with the right parameters — you don’t need to know the check_id or resource_id in advance. Just refer to the finding naturally.

Simple acceptance (no expiry)

“Accept the risk on that S3 public access finding — that bucket is internal tooling reviewed by the security team.”

Acceptance with an expiry

“Accept the risk on the CloudTrail finding, expires in 90 days. Reason: enabling logging next sprint.”

“Mark that IAM finding as accepted — we’re decommissioning the role by end of month.”

After Claude identifies a finding

“OK, accept that one. Reason: legal reviewed and approved this configuration for the EU data residency setup.”

What Claude asks before accepting

Claude will confirm the finding details before accepting — the resource name, region, and the reason you’re providing. This prevents accidental acceptances and gives you a chance to review before the record is created.

Setting an expiry

Expiry dates are strongly recommended. They force a periodic review of accepted risks so they don’t become permanently invisible. Common patterns:

Situation	Suggested expiry
Decommissioning a resource next quarter	90 days
Waiting for a vendor fix	60–90 days
Short-term architectural exception	30 days
Permanent architectural decision (rare)	No expiry, with a very specific reason

“Accept that finding, expires in 60 days — we’re waiting for the vendor patch.”

Viewing accepted risks

Use list_acceptances to see your full risk register at any time.

“What risks have we accepted?"
"Show me our risk register"
"Which findings are currently waived and when do they expire?"
"Are any risk acceptances expiring this month?”

The response includes the finding, the reason, who accepted it, when it was accepted, and the expiry date if set.

Revoking an acceptance

If circumstances change and you want a previously accepted risk back in your active findings, ask Claude to revoke it.

“Revoke the acceptance on the S3 public access finding — we’re keeping that bucket."
"Remove the waiver on the CloudTrail finding, we’re not fixing it after all.”

Once revoked, the finding returns to active on the next scan and is visible in your dashboard and MCP queries again.

What you cannot accept

Findings that don’t exist in your most recent scan (you can’t pre-accept hypothetical risks)
The same finding twice — each finding pattern (check + resource + region) has one active acceptance per org at a time
Findings on behalf of another org (acceptances are scoped to your organisation)

Audit trail

Every acceptance — creation, expiry, and revocation — is recorded with a timestamp and the user who took the action. This gives auditors a full history of risk decisions, which is particularly useful for SOC2 Type II audits where evidence of your risk management process is required.

“Show me all risk acceptances including expired ones"
"Who accepted the IAM finding last month?”