An exception is not automatically a finding
An exception marker identifies something that needs attention in a procedure. It is not necessarily the final statement of a finding. A person still needs to decide what was observed, how to describe it and which severity is appropriate.
RiskSensai preserves that distinction. Marking a procedure as an exception alone does not create a finding. The engagement workflow provides an explicit Create finding action where the workspace, role and engagement state permit it. That action asks a human to review the finding before submission.
This walkthrough concerns that narrow action. It does not promise that the entire internal-audit roadmap is available in every account. Current navigation can omit this workspace; opening a protected route does not activate a feature or grant access.
Confirm the engagement context
The platform’s public security information explains the general organization-access boundary.1
Open an engagement you are authorized to work on in the correct organization. Review the engagement and the relevant procedure before selecting an action. The finding belongs to that organization and engagement context, so a description from another engagement should not be copied without examining its relevance.
Existing boundaries remain in effect. Read-only users do not receive the writing action. Cross-organization access is denied, and closed or cancelled engagement states do not become writable through the finding form. If the action is absent or denied, resolve the legitimate access or state question rather than looking for a bypass.
An exception itself may need investigation. If the underlying observation is unclear, gather the relevant facts before drafting a conclusion. A finding should make uncertainty understandable rather than disguise it with a polished title.
Select the explicit action
On the relevant exception procedure, choose Create finding when offered. Treat the form as a review step. The procedure’s exception status is context for your decision; it is not an automatic instruction to generate a finding.
The essential reviewed fields are title and severity. A blank or unreviewed title should not pass as a completed finding, and severity must be deliberately selected. Where additional details are available, use them to explain what the observation means and what remains unconfirmed.
Do not assign severity simply to make the queue appear orderly. Use your organization’s approved criteria and the actual circumstances. The platform provides a selection, not a substitute for that judgment.
Write a title someone can investigate
| Weak title | More useful direction |
|---|---|
| Access issue | Identify the system and the particular review gap |
| Failed procedure | Describe the observed exception rather than the procedure’s status alone |
| Non-compliant | State the specific requirement or expectation and the observed departure, if established |
An illustrative title might be “Finance application access review excludes service accounts.” It identifies a reviewable condition without asserting broader coverage than the evidence supports. If the population is not yet confirmed, say so in the explanation rather than presenting a tentative inference as a fact.
Avoid including unnecessary personal data in a title. The title can appear in a list and may be visible to a wider authorized audience than a private underlying document.
Review before submitting
Use a short final check:
- The organization and engagement are correct.
- The finding describes the observation you actually reviewed.
- The title is clear and contains no unnecessary sensitive information.
- Severity follows the relevant human criteria.
- Any unresolved evidence or scope limit is stated honestly.
Then submit once and wait for the response. The interface prevents duplicate pending submissions from repeated clicks on the same action. That protection should not be interpreted as a universal guarantee that separately initiated requests can never create duplicates.
Do not keep clicking because a response takes longer than expected. A pending operation is still an operation whose outcome needs to be established.
Confirm the saved result
After successful creation, the interface provides confirmation and an Issue Center link. Use that receipt to inspect the saved finding. Check the title, severity and engagement context before treating the action as complete.
The finding retains the organization and engagement it came from. Record the relevant procedure in your explanation when needed, rather than assuming the system stores every procedure relationship separately. Engagement context helps a colleague understand the source; it does not by itself establish a verified chain of evidence.
The Issue Center is the place to continue owned remediation work where your role permits it. Creating a finding does not automatically assign a task, verify a fix or close the issue.
Handle a failure without manufacturing certainty
A clear denial and an uncertain write are different. A denial tells you the action was not permitted. An uncertain response means you should determine whether the record was saved before attempting another creation.
If the form reports uncertainty, inspect the engagement’s relevant findings or Issue Center and preserve the error information. Do not automatically retry. A second submission can create a new record even if the first succeeded but its response was lost.
If the saved state cannot be established, ask the organization owner or support to investigate. Describe the intended action and time without sharing another user’s credentials or unrelated confidential evidence.
Keep the finding’s meaning proportionate
A finding is an operational record for investigation and remediation. Its creation is not an independent audit opinion, certification or legal conclusion. RiskSensai’s published transparency information keeps those assurance boundaries explicit.2
The assessment’s informational priorities are also distinct from this reviewed engagement action. A questionnaire answer can suggest an area to examine; it is not automatic evidence that an exception finding should be created.3
The workflow is complete when you have an honest finding, a deliberate severity, a confirmed saved receipt and a clear next owner for any further work. The explicit human step protects that meaning: an exception can prompt investigation without silently turning every marker into a new finding.
Sources and references
-
RiskSensai. RiskSensai Security. Describes current evidence and access-control limits. ↩
-
RiskSensai. RiskSensai Trust Center. States readiness and formal-assurance boundaries. ↩
-
RiskSensai. Free Digital Trust Assessment. Explains self-reported scope and authenticated assessment entry. ↩

