Sample report
Sample security closure record
This example shows how a finding can move from assessment through approved remediation, verification and evidence.
SYNTHETIC SAMPLE — NOT A CUSTOMER REPORT
About this sample
All environments, resources, findings, timestamps and identities shown here are synthetic examples created for illustration.
- It is not a report for, or about, any real organisation.
- It is not an audit, a certification report or a penetration test report.
- It is not evidence from a real engagement, and it does not show results anyone has achieved.
Sample record
Report metadata
- Record
- Sample security closure record
- Reference
- SAMPLE-0001
- Organisation
- Example Organisation (synthetic)
- Environment
- synthetic-environment
- Cloud
- Microsoft Azure
- Subscription
- example-subscription
- Access for checking
- Read-only: a service principal with the built-in Reader role.
- Scope of this record
- One control on one resource
SYNTHETIC SAMPLE — NOT A CUSTOMER REPORT. All environments, resources, findings, timestamps and identities shown here are synthetic examples created for illustration.
Sample record · Finding
Finding summary
Public blob access is allowed on storage account samplestorage01
No storage bucket is public. Anyone with the link can read the contents, and exported files often contain customer personal data.
Sample record · Assessment
Assessment detail
- Control
- No storage bucket is public (TC-DATA-02)
- Resource
- samplestorage01 · storage account · example-resource-group
- Observed state
- Public blob access: allowed
- Expected state
- Public blob access: disallowed on the storage account
- Result
- Failing
- Severity
- Critical: fix first.
- Why it matters
- Anyone with the link can read the contents, and exported files often contain customer personal data.
- Assessment time
- Sample day 1, 09:40
How the check is made
- Checking your controls needs read-only access.
- Each control is checked by a defined rule. AI does not decide whether a control passes.
- If a control cannot be checked, we say so. It is never counted as passing.
Sample record · Plan
Remediation plan
Finding → remediation decision → approved change → bounded execution → verification.
01 Finding
SYNTHETIC SAMPLE — NOT A CUSTOMER REPORT- What the engineers do
- Confirm the finding, and whether any application depends on public access to this storage account.
- What ARIA supports
- The defined check reports the control as failing on samplestorage01.
02 Remediation decision
SYNTHETIC SAMPLE — NOT A CUSTOMER REPORT- What the engineers do
- Decide that public access is not needed, agree the change with the owning engineers and plan the rollback: allow public access again on this one account.
- What ARIA supports
- Nothing. This decision is made by people.
03 Approved change
SYNTHETIC SAMPLE — NOT A CUSTOMER REPORT- What the engineers do
- Example Security Approver, a named person in the example organisation, reviews and approves the one change.
- What ARIA supports
- Records the request and the approval. The approval is one-time and expires.
04 Bounded execution
SYNTHETIC SAMPLE — NOT A CUSTOMER REPORT- What the engineers do
- Stay available to roll back if an application is affected.
- What ARIA supports
- Re-checks the control before the change runs, then changes one setting on samplestorage01 and nothing else.
05 Verification
SYNTHETIC SAMPLE — NOT A CUSTOMER REPORT- What the engineers do
- Review the result, and confirm the applications that use the account still work.
- What ARIA supports
- Runs the same check again straight away and records the outcome.
Sample record · Approval
Approval record
Nothing in this sample changed until a named person in the example organisation approved it.
- Proposed change
- Disallow public blob access on samplestorage01
- Requested by
- Example Security Engineer (synthetic)
- Approver
- Example Security Approver (synthetic)
- Authorization
- Approved
- Scope
- One setting on one resource: samplestorage01
- Requested
- Sample day 1, 10:55
- Approved
- Sample day 1, 11:05
How approval works
- Nothing changes in your cloud until someone with approval rights approves it.
- An approval is valid for a limited time. After that, it must be approved again.
- Applying a fix needs an additional, narrowly scoped permission for that one kind of change. You grant it only if you want Tricognita to apply fixes.
- Each kind of automated fix is off by default. It is switched on per organisation.
Sample record · Fix
Remediation action
- Action
- Disallow public blob access
- Resource
- samplestorage01
- Setting
- allowBlobPublicAccess
- Before
- true (public blob access allowed)
- After
- false (public blob access disallowed)
- Applied
- Sample day 1, 11:12
- State
- Applied
The change was made. Whether it fixed the control is shown separately.
What the change is bounded to
- A fix changes one setting on the one resource that failed. It cannot be pointed at anything else.
- No other storage account, container or setting in the subscription is changed.
Complex or unsupported changes remain engineering-led. Your engineers, or ours when you work with us, make the change, and it is tracked and verified the same way.
Sample record · Verify
Verification result
The check that found the problem confirms the fix. Only a passing check counts as fixed. The finding is not closed until the check runs again.
- Before: Control checkedSample day 1, 09:40Failing
- Change: Approved remediation appliedSample day 1, 11:12Applied
- After: Same check run againSample day 1, 11:13Passing
Outcome
- FixedThis sample
A fresh check confirms the control now passes.
- Did not fix it
The change was made and the control still does not pass.
- Unconfirmed
The change was made. The control could not be re-checked, so nothing is claimed.
How verification works
- After a fix is applied, the control is checked again straight away.
- Each fix ends in one of three outcomes: Fixed, Did not fix it, or Unconfirmed.
- Verification shows that a specific control passes after a specific change. It does not mean the whole environment is secure.
Sample record · Evidence
Evidence record
- Record type
- Remediation
- What it holds
- The change that was applied, and the check that confirmed it.
- Control
- No storage bucket is public (TC-DATA-02)
- Resources
- samplestorage01
- Time
- Sample day 1, 11:13
- Result
- Passing · Fixed
- Integrity on retrieval
- Integrity check passed
- 1. Assessment checkSample day 1, 09:40Failing
- 2. Fix requestedSample day 1, 10:55 · linked to record 1Awaiting approval
- 3. ApprovalSample day 1, 11:05 · linked to record 2Approved
- 4. Change appliedSample day 1, 11:12 · linked to record 3Applied
- 5. Verification checkSample day 1, 11:13 · linked to record 4Passing
How records are kept
- Every check is saved as an evidence record: the control, the resources, the time and the result.
- Each evidence record is signed and linked to the one before it.
- When a record is opened, the product checks it still matches what was written.
- Every request, approval and change is recorded in a linked audit log.
Sample record · Closure
Closure record
What failed, what changed, who approved it, whether the fix worked and whether it stayed fixed. It is a record of what happened, not an audit opinion.
01
Finding
Identified02
Authorization
Approved03
Remediation
Applied04
Verification
Fixed05
Evidence
Recorded06
Closure
ClosedFinding marked resolved
Controls are re-checked on a schedule. A control that passed and later fails is flagged as drifted, so it can be fixed and verified again.
SYNTHETIC SAMPLE — NOT A CUSTOMER REPORT. All environments, resources, findings, timestamps and identities shown here are synthetic examples created for illustration.
ARIA
Where ARIA fits
ARIA · Cloud control remediation and verification
ARIA is Tricognita's product for cloud control remediation and verification. It makes the repeatable parts of this record consistent: the check, the bounded change, the re-check and the records.
It does not decide what to change, approve changes or replace engineering judgement. People made every decision in this sample.
This sample was written by Tricognita to illustrate the workflow. It is not a report generated by ARIA.
Evaluate → Fix → Verify → Keep secure → Evidence
Evaluate
Check each control on each resource from read-only access.
In this sample: The failing control was found by a defined check.
Assessment detailFix
Approved, bounded remediation where the cloud's fix capability supports it.
In this sample: The approved, bounded change was applied to one resource.
Remediation actionVerify
Re-run the same check; only a passing check counts.
In this sample: The same check ran again and the control passed.
Verification resultKeep secure
Re-check on a schedule and flag drift.
In this sample: A later scheduled re-check still passed.
Closure recordEvidence
Signed, linked records and a closure record.
In this sample: Each step was saved as a signed, linked record.
Evidence record
Where these capabilities stand today
The sample illustrates the workflow. It does not change what is available. Shown on Microsoft Azure.
- Control evaluation on Microsoft Azure
- Launching
- Named, time-limited approvals
- Launching
- Customer-authorised fixes on Azure
- Launching
- Tracking for fixes your team applies
- Launching
- Same-check verification
- Launching
- Scheduled re-checks and drift detection
- Launching
- Signed, linked evidence records
- Launching
- Verified closure record
- Launching
Where Tricognita Services fit
Our engineers carry the work in this record, in this order.
- 1. AssessmentFinds and ranks what fails.Cloud Security Assessment Available
- 2. RemediationPlans and applies each fix with your engineers.Remediation & Hardening Available
- 3. VerificationRe-checks each fix and records whether it held.Remediation & Hardening Available
- 4. Ongoing supportRe-checks and drift fixes, where you want the work to continue.Security Retainer Available
People decide
Human decision boundary
ARIA acts only on a change a named person has approved, and only within the bounds shown above. These decisions stay with people, always.
- Defining the scope of the work
- Prioritising risk
- Deciding what should change
- Approving authorized fixes: a named person in your organisation
- Accepting risk that will not be fixed now
- Authorizing changes to production
- Final operational decisions about your systems
Start with a Cloud Security Assessment.
Tell us about your cloud and what you need to fix or prove. You receive a written scope before any work starts.