Skip to main content
All articles

Product Workflows / Product walkthrough

Create a Finding From an Exception Procedure in RiskSensai

By RiskSensai5 min read
Editorial archive date
First published
Facts checked

The archive date places this article in the editorial collection. It is not an original publication date. Guidance reflects the fact-check date above.

Create a Finding From an Exception Procedure in RiskSensai: original RiskSensai editorial cover

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 titleMore useful direction
Access issueIdentify the system and the particular review gap
Failed procedureDescribe the observed exception rather than the procedure’s status alone
Non-compliantState 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:

  1. The organization and engagement are correct.
  2. The finding describes the observation you actually reviewed.
  3. The title is clear and contains no unnecessary sensitive information.
  4. Severity follows the relevant human criteria.
  5. 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

  1. RiskSensai. RiskSensai Security. Describes current evidence and access-control limits. ↩

  2. RiskSensai. RiskSensai Trust Center. States readiness and formal-assurance boundaries. ↩

  3. RiskSensai. Free Digital Trust Assessment. Explains self-reported scope and authenticated assessment entry. ↩

General educational information, not legal advice, a professional audit opinion, certification, or a guarantee. Applicability and conclusions depend on your organization and should be assessed by an appropriately qualified professional.

Prepared with AI assistance and automated editorial checks. This does not indicate independent professional review or verification of your organization.

  • Internal Audit
  • Findings
  • Exceptions
Connecting to your conversation workspace…