A risk-assessment interview example without invented precision

A useful risk-assessment answer connects a possible event, the conditions that allow it, the affected business activity and the consequence. Explain the evidence and uncertainty before assigning a rating. A number without a defined scale or supporting rationale adds little.

The original fictional case below is a practice conversation about a proposed response. It is not a security assessment of a real organization or a recommended scoring model.

Define one scenario

At fictional Rowan Studio, project teams share draft client files through links. The exercise package states that links can be forwarded, external recipients are not individually restricted, and the supplied configuration record shows no automatic link expiry. The team wants to keep sharing convenient during client reviews.

A bounded scenario is: “A forwarded link could allow an unintended recipient to access a client draft, exposing material outside the intended review group.”

This is clearer than “file sharing is high risk.” It identifies a route to exposure and a consequence. It does not establish that a disclosure has happened, how often it is likely, or which obligations apply to every file.

Separate known conditions from missing information

Known in the exercise	Still to establish
Forwarding is possible under the stated sharing configuration	Whether additional access restrictions apply outside the supplied record
Client drafts are shared	Their sensitivity and any applicable handling requirements
No automatic expiry appears in the supplied configuration record	How owners currently revoke links and whether that process is followed
Client review depends on collaboration	The operational effect of each proposed restriction

Ask for the facts that could materially change the assessment. Do not demand every conceivable document before identifying the immediate decision. The business owner can help explain the work; a system owner can clarify the actual configuration and available controls.

Compare responses against the scenario

Consider three options for discussion, subject to technical feasibility and organizational approval:

Restrict access to named recipients. This addresses access by an unintended recipient of a forwarded link, but requires a workable identity and invitation process.
Introduce an agreed expiry period. This may reduce the duration of exposure, but an unintended recipient could still use an accessible link before expiry.
Use a separately approved sharing method for sensitive drafts. This may change the exposure, while introducing a workflow the team must understand and be able to use.

The options need not be mutually exclusive. Explain which part of the scenario each affects and what it leaves unresolved. Do not claim that adding one control removes all residual risk.

Before recommending a setting, check that it is supported and that its behavior matches the assumption. A product label such as “private link” is not enough to establish who can access it.

A worked answer to the rating question

The interviewer asks, “Is it high, medium or low?” A defensible response can still be direct:

I would apply your defined rating criteria after confirming the file sensitivity, access behavior and likely business consequence. From this package, I can identify a plausible unintended-access scenario and a configuration that appears to permit it. I cannot justify a probability or a rating threshold from the information supplied. My immediate recommendation would be to confirm the access behavior and compare recipient restriction with the client-review workflow, then bring the options and remaining uncertainty to the owner.

If the interviewer supplies a defined scale, use it. Explain the mapping rather than refusing all ratings. If the scale distinguishes impact from likelihood, keep those judgments separate before combining them according to that method.

Do not turn “we have no recorded incidents” into a numerical likelihood. First establish what incident information exists, what it covers and whether the relevant activity would have been observed.

Give the decision an owner and a review point

A recommendation is incomplete if nobody knows what happens next. In this exercise, assign the system owner to confirm behavior, the business owner to describe client-review needs, and the authorized decision-maker to choose or accept a response under the organization's process.

A useful review point is tied to evidence or a change: after the sharing configuration is confirmed, after a pilot of named-recipient access, or when the file types or external audience change. Merely adding a date to a risk register does not establish that a control worked.

For interview practice, close with what you would record: the scenario, evidence references, assumptions, chosen response, decision owner and conditions requiring reassessment.

Practice a change in the facts

Now assume a verified demonstration shows that every external recipient must authenticate and that forwarding the link alone does not grant access. Revise the original access assumption. You may need a different scenario, such as an incorrectly authorized recipient, but do not preserve the original rationale after evidence contradicts it.

NIST SP 800-30 Rev. 1 provides formal risk-assessment guidance. This article's scenario and answer structure are original educational material, not a substitute for an organization's assessment method.

Try the free evidence worksheet, then inspect the Interview Case Workbook sample for more original decision practice. Find related explanations in the field-note library.

Turn the reasoning into a maintained record with the worked risk-register example, including a revision when evidence changes.

For a comparison of free practice and the full book, read the risk-assessment workbook selection page.