MyRISK Trace · for legal, records and security
Your records in MyRISK Trace
Somebody has sent you this because they want to put a decision that matters into Trace, and you have to say whether that is acceptable. It covers what the record holds, what Trace verifies and what it does not, who can reach it, where it is held, how long it stays, how it is corrected, and what an export leaves behind.
What this page is, and what it is not
- Trace independently verifies the elements of a high-stakes decision against formal audit assertions, records how the decision was made, and can replay it later — including with elements of the decision changed. It does not make the decision for you, and the assertions it tests are yours.
- Applying the assertions is not an audit, a review or an assurance engagement under ASAE 3000 or any other standard. The governing text is clause 15 of the licence agreement, linked at the foot of this page.
- This page describes the hosted service. Where you run the optional gateway in your own environment, its host, storage and access are under your controls — see Deploying MyRISK Trace.
What a record holds
A Trace record is built as the decision happens, and holds:
- The evidence available at the time, or a reference to it.
- The reasoning, and the governing policy version that applied.
- Who authorised it, and under what delegation.
- The conditions and the expiry attached to the approval.
- The assertions tested against the decision, and what each returned.
- What changed afterwards, as later events rather than edits.
What the decision is tested against
Trace independently verifies the elements of a decision. It does not take the decision on trust and file it. Each element is tested on its own — that an authorisation was obtained, that it came before the act rather than after it, that the person who gave it held the delegation relied on, that the required evidence exists, that the stated conditions were met — and the results are part of the record.
The tests are audit assertions. Not a checklist, and not a rules engine written for this product: a control objective is restated as a formal assertion in the sense audit uses the word, and each assertion is paired with a test and a pass condition that makes it decidable. The classical set — occurrence, completeness, accuracy, cut-off, classification, existence, rights and obligations, valuation, and presentation and disclosure — restates in a technology context as completeness, accuracy, validity and restricted access. An assertion reads like “an authorisation has occurred prior to every change”, or “all events that should have been recorded have been recorded”: a sentence that is true or false about the decision, rather than a matter of opinion.
This is MyRISK's own method, published before the product existed. Prioritise what to monitor, turn control objectives into formal assertions, then define the automated test and pass condition for each. It is set out in full in A Practical Approach to Continuous Controls Monitoring, first published in the ISACA Journal in 2015.
The tests are deterministic. The same decision and the same inputs produce the same result, every time and for whoever runs them. Nothing about the outcome depends on when it was run or who ran it, and an auditor can re-run them rather than take the result on trust.
The assertions are yours. They are defined by you, or defined with you in a consulting engagement, against your own policy, risk appetite and obligations. MyRISK supplies the method and the machinery, not a view about your decision.
A record can be replayed, and replayed with something changed. Replaying re-runs the assertions over the recorded decision, which is how a result is explained later. Elements can be changed in a replay — a different threshold, a revised approval, evidence that has since arrived — to show what the result would have been.
What the tests do not do
They decide the assertions put to them, and nothing beyond. They do not form a professional opinion on whether the decision was a good one, and applying them is not an audit, a review or an assurance engagement under ASAE 3000 or any other standard. Where an element rests on an authorised person's declaration rather than on evidence Trace can reach and test, the record says so — and confirming that person's identity and authority remains the responsibility of the system they are using.
Who can reach it
Your records are separated from every other customer's by Oracle Virtual Private Database policies in the MyRISK platform, supported by application permissions and tenancy controls.
Access is by role. The default roles are Tenant Administrator, Viewer, Risk Manager, IT Manager and Responder, and they can be tailored to control which screens and actions a person reaches.
Decision responsibilities are recorded separately from access. Approvers, risk owners and evidence providers are part of the decision history; they are not the same thing as a person's permissions in the platform.
Two limits
- Access cannot currently be restricted to a single record or class of decision through the gateway's own user management. Where the gateway is reachable by more than one person, it sits behind your own authentication and access control.
- Reading a record is not logged. Material changes, lifecycle events and exports are audited, and sign-in and sign-out are logged — every individual view is not.
Where it is held
The hosted service runs on shared Oracle Cloud infrastructure in the Sydney region. Customers do not receive a separate physical database by default, and region selection is not a self-service option — specific hosting requirements are part of a deployment conversation rather than a setting.
Oracle Autonomous Database encrypts data at rest, and traffic to the service is encrypted in transit.
Where the optional gateway runs in your environment, its local data sits on your infrastructure, and encryption of that host, its storage and its backups is under your controls.
How long it stays
There is no default retention period, and a record persists until someone acts. That is deliberate: Trace exists to be a durable record of how a decision was made.
Your retention requirements are agreed during implementation, against the legal, regulatory and records-management obligations you actually carry.
There is no automatic expiry or disposal. Where you require retention-based disposal, the treatment is designed with you — deletion, archival, restricted access, or referral to a person for approval — and the disposal itself can be recorded, including when it happened and who authorised it.
How it is corrected, and what can be removed
Corrections are append-only and never overwrite. A correction is a new event; the original stays and the history shows both.
There is no self-service deletion of an authoritative decision record. Where you have a legal or contractual deletion requirement, an authorised disposal process is agreed with you, and it defines three things: who approves the deletion, what may be removed, and what enduring audit record of the action remains.
The way to hold less is to reference more, which is the next section.
Privileged and sensitive material
A document does not have to enter Trace to be part of the record. Trace can hold a reference, a link, a cryptographic hash, descriptive metadata, or an authorised user's declaration — so the material itself stays in your own repository.
What the record then carries is what evidence was considered, where it is held, who supplied it, when it was considered, and any declaration made about its relevance.
An item can be marked privileged and excluded from replay and from export. Privileged material is excluded from exports by default, and including it requires a deliberate decision by you.
Where Trace relies on a declaration instead of the document, the record says so. Confirming the identity and the authority of the person making that declaration remains the responsibility of the system they are using.
Export, and the log of exports
A case exports in JSON and CSV, and a PDF report of the whole case can be compiled — the record as a document, for the reader who needs to be handed one rather than given a file to parse.
Every export is recorded, whatever the format, and the entry holds:
- Who generated it, and when.
- Which case was exported.
- The format and scope.
- The stated purpose.
- Whether privileged material was included.
- How many items were excluded.
- A cryptographic hash of the output.
The export is also an event in the decision's own history, and authorised users or systems can retrieve the recent export history for a case.
Use in audit
Replayability is a property of the record, not a legal conclusion. “Audit-ready” is not promised; acceptance is your auditor's.
A record is built to be explained later — what was known, who approved it, what conditions applied, which assertions were tested and what each returned, and what has changed since. Because the assertions are formal and the tests deterministic, an auditor can re-run them and get the same answer rather than take the result on trust, which is the point of expressing a control objective as an assertion in the first place. Whether that satisfies a particular auditor, regulator or court is still their judgement to make.
Statement of Responsibility
The Statement of Responsibility is clause 15 of the MyRISK End User Licence Agreement, which is the governing text.
It sets out five things: that establishing and maintaining internal control is the Customer's responsibility; what a Trace record is, what it verifies and what it does not; the inherent limitations of any control structure, and that a record is not a comprehensive statement of every weakness; that acceptance by a court, regulator or auditor is that body's decision and no outcome is promised; and that MyRISK does not provide legal advice.
Which decision would be hardest to defend next month?
Bring that one. The Diagnostic compares your current reconstruction with a Trace-style replay.