A Practical Risk Assessment for Your Transfer Estate

The last risk register I inherited was a spreadsheet with three colors, no dates, and a tab called "final v2." Every cell was green except the one about the firewall, which was greener. "Risk assessment" is a phrase that smells of consultants, binders, and meetings that produce more meetings. That spreadsheet is what the ceremony usually leaves behind. Underneath it sits something an administrator can do alone in an afternoon. List the file flows you run. Name what could realistically go wrong with each. Score how likely and how damaging each event would be, then multiply. Fix things in the order the numbers suggest. The output is one page. The value is that your limited security time finally goes where it matters, instead of where the last scary headline pointed.

This article is the whole method. It covers building on your flow inventory and naming risks so they can be scored. It gives anchored 1-to-3 scales for likelihood and impact, and the matrix that turns scores into priorities. It includes a worked pass over a small realistic estate, and a one-page risk register template you can copy today. It is the capstone of our File Transfer Threat Modeling series. The earlier articles taught you to see threats; this one turns what you saw into a ranked to-do list. Colors optional.

What a Risk Assessment Actually Is

In this context, a risk is a possible bad event with a consequence attached — "partner credentials are guessed, and a stranger reads three months of order files." A risk assessment is the disciplined comparison of those events. Estimate each one's likelihood (how plausibly it happens to you) and impact (how bad the day is when it does). Use the combination to decide what gets fixed first. The multiplication is not science and does not pretend to be. It is a forcing function that makes you compare risks against each other instead of treating everything as equally urgent. In practice, treating everything as equally urgent means treating everything as equally ignorable.

Two honest boundaries before we start. First, scoring is judgment wearing numbers, and that is fine: the goal is consistent relative ranking, not actuarial truth. Second, the assessment is only as good as the inventory underneath it. A risk you never wrote down scores zero by default. The estate's most dangerous flows are usually the undocumented ones. Which is why the method starts where it starts.

This document also has an audience beyond you. Security questionnaires from customers, due-diligence reviews, insurance applications, and audit frameworks all eventually ask some version of the same question. It is "have you assessed the risks to data you transfer, and can you show the assessment?" A one-page register with scores, decisions, and review dates answers that question in thirty seconds. The same page, kept current, is the artifact a successor thanks you for and an incident review builds on. You are writing for three readers: yourself today, an auditor eventually, and whoever holds this job after you. Write it so the third one can read it without calling you.

Start from the Flow Inventory

The foundation is a list of every recurring transfer you operate — one row per flow, with its protocol, endpoints, data description, and owner. Building that list is its own project, covered end to end in our companion article on running a file flow census. If you have done that census, the risk assessment inherits its rows directly. The two documents stay joined at the hip from then on. The census says what exists. The register says what could go wrong with it.

If you have no census yet, do not stall the assessment waiting for a perfect one. Run the abbreviated version. List the flows you can name from memory. Add whatever your firewall rules and scheduled-task lists reveal in an hour of looking. Accept that the first pass covers the estate you know. Note "complete the census" as its own action item. An unknown flow is itself a risk, and it belongs on the register in exactly those words. For each flow you list, capture the four facts scoring will need. Record what data it carries (and how sensitive), and what protocol it uses (encrypted or not). Record who can reach it (internet-facing or internal), and what depends on it (what breaks or leaks if the flow fails or is abused).

Naming Risks So They Can Be Scored

The most common failure in amateur risk work happens before any scoring: vague entries. "FTP" is not a risk. "Security of the partner server" is not a risk. Neither can be scored, owned, or fixed. A workable risk names three things in one sentence — threat, event, consequence:

[threat] causes [event], resulting in [consequence]

Weak:   "The FTP server is old."
Usable: "An eavesdropper on the network path captures plain-FTP
         credentials for the payroll flow, resulting in exposure of
         employee bank details and an impersonated partner login."

Weak:   "Insider risk."
Usable: "A departing employee bulk-downloads the customer folder
         before their last day, resulting in client data leaving
         with them."

Where do candidate risks come from? You have already met the sources in this series. A per-flow threat modeling pass generates them hop by hop. The six common attack families are a ready-made checklist to hold against every internet-facing flow. The insider scenarios supply the risks that originate behind your own authentication. And your attack surface findings from earlier in the series — the forgotten port, the stale accounts, the exposed admin panel — convert one-for-one into register rows. Write each candidate in threat-event-consequence form against the flow it belongs to, and you are ready to score.

Scoring Likelihood Without Kidding Yourself

Use a 1-to-3 scale, and anchor each number to something concrete so that two administrators scoring the same risk land close together:

• 3 — Expected. Use this score if automation attempts this continuously against everything reachable (credential guessing on any internet-facing login). Also use it if the event has already happened here at least once, or the weakness is present and trivially findable.
• 2 — Plausible. Requires modest effort, inside access, or a known weakness that is real but not advertised — a readable stored password, a cleartext protocol on a shared network segment.
• 1 — Unlikely. Requires a capable, motivated, targeted attacker or an unusual accident — interception inside a provider's backbone, a trusted senior insider acting deliberately.

Two disciplines keep the numbers honest. Score the flow as it is today, current controls included — the register records residual risk, not the risk of some hypothetical naked system. And use your own evidence: your authentication logs already tell you whether guessing attempts are theory or a nightly fact. Optimism is the chronic disease of self-assessment; logs are the cure.

Scoring Impact Without Drama

Impact gets the same anchored 1-to-3 treatment, judged on the worst plausible outcome of the event — not the most catastrophic imaginable one:

• 3 — Severe. This means regulatory notification territory (personal, financial, or health data exposed), breach of a contractual obligation to a partner, or serious operational harm. It is the kind of day that involves executives and outside counsel.
• 2 — Disruptive. Recoverable damage: a flow down long enough to hurt, an awkward-but-survivable partner conversation, cleanup measured in days.
• 1 — Annoying. Contained nuisance: junk in an upload folder, a scanner filling a disk, rework measured in hours.

Three inputs decide the number. They are the sensitivity of the data in the flow, the business weight of the process depending on it, and the blast radius. Blast radius means whether the event stays contained to one folder and one partner or opens onto the wider network. A risk might hand an attacker a foothold (a compromised transfer host, an exposed admin interface). Score its impact for where the foothold leads, not just for the box itself.

The Likelihood × Impact Matrix

Multiplying the two scores places every risk in a 3-by-3 grid. The matrix below is the whole scoring system on one screen. Scores of 6 or 9 demand action. Scores of 3 to 4 get scheduled. Scores of 1 to 2 get watched:

Matrices like this get criticized in risk literature, correctly, for manufacturing precision — the difference between a 4 and a 6 is judgment, not measurement. Use the grid for what it is good at: separating the plainly urgent from the plainly deferrable, and forcing the argument about the middle. When two risks tie, the tie-breaker is not another decimal place. It is the question "which fix is cheaper, and which failure is harder to detect?" Undetectable failures deserve the nudge upward, because they run longest before anyone notices. I have spent an hour arguing a 4 against a 6, and regretted the hour.

A Worked Pass over Four Flows

Here is the method applied to a small, realistic estate — four flows, scored with the anchors above:

• Nightly partner flow over plain FTP, carrying order and account data. Eavesdropping captures credentials and file contents: likelihood 2 (needs path position, but the weakness is total), impact 3 (customer account data, contractual exposure). Score 6 — High. The fix is migration to an encrypted protocol, the program our retiring plain FTP series lays out.
• Internet-facing SFTP endpoint, password-only, no lockout policy. Credential guessing eventually lands on a weak partner password. Likelihood is 3 (your logs show the attempts tonight). Impact is 2 (each partner confined to one folder — containment already limits the blast). Score 6 — High. Lockouts, throttling, and key-based logins — the brute-force protection series — collapse the likelihood to 1.
• Internal server-to-server sync between two machine-room hosts. Interception requires an intruder already inside, likelihood 1; impact 2 (operational data, contained). Score 2 — Low. Watch it; spend nothing yet.
• Anonymous internal upload drop for a legacy scanner. Abuse as a staging point for hostile files: likelihood 2 (internal-only, but unauthenticated), impact 2 (downstream machines trust the folder). Score 4 — Medium. Schedule containment; the device itself may justify a documented exception, the kind examined honestly in when plain FTP is acceptable.

The numbers just ordered a migration project, a configuration change, a deferral, and a containment task, four different kinds of work, on one scale. That comparison across unlike things is the entire product of a risk assessment.

Acme's first pass came out differently from the example above, which is the point of doing your own. The top row was not a protocol or a port. It was the SSH key that authenticated the payroll feed to Kestrel Payroll. Someone who had since changed roles had generated it, and it had never been rotated. It was present on two decommissioned hosts and one old backup set that nobody could account for. It had likelihood 2 and impact 3. The fix took an afternoon: a new key pair, the old one revoked at the partner end, and a rotation date written on the register. It was closed that week, which is what a top row is for. Nobody had done anything careless. The key had outlived every reason anyone had to look at it.

The One-Page Risk Register

The register is where scores become commitments. One page, deliberately — the constraint is a feature, forcing consolidation and pruning. Copy this template and replace the examples with your own rows:

TRANSFER RISK REGISTER — scope: <which servers/flows>
Owner: <name>    Last reviewed: <when>    Next review: <when>

ID  FLOW              RISK (threat -> event -> consequence)        L  I  SCORE
R1  Partner orders    Eavesdropper captures plain-FTP credentials  2  3    6
    (nightly FTP)     -> flow impersonated, account data exposed
                      Controls today: password only
                      Decision: MITIGATE — migrate flow to SFTP
                      Action & owner: <name>, by <when>

R2  Inbound SFTP      Password guessing succeeds on partner acct   3  2    6
    (partner drops)   -> foreign files planted, drop data read
                      Controls today: per-partner folders,
                      activity logging reviewed weekly
                      Decision: MITIGATE — lockouts + key auth
                      Action & owner: <name>, by <when>

R3  Scanner drop      Unauthenticated area used to stage hostile   2  2    4
    (legacy device)   files -> internal clients fetch them
                      Controls today: internal-only reachability
                      Decision: ACCEPT until device replaced
                      Accepted by: <name>, revisit <when>

RULES
- RISK column is always threat -> event -> consequence
- L and I use the anchored 1-3 scales; score with today's controls
- DECISION is one of: MITIGATE / ACCEPT (name + revisit date) /
  AVOID (retire the flow) / TRANSFER (shift it contractually)
- Keep it to one page: consolidate, prune, or you are keeping
  a worry list, not a register

The "controls today" line matters more than it looks: it records what actually exists, verified — not what is planned or assumed. If a row claims "activity logging reviewed weekly," that claim should survive an audit. A server whose activity log genuinely captures each session, as Sysax Multi Server's does, gives that line something real to point at. Registers rot from aspirational entries.

Deciding What to Fix First

Sort by score, then apply judgment where the arithmetic ties. Three rules produce a defensible order:

1. Criticals and Highs get dates and owners now. Not a severity label — a name and a deadline. A High without an owner is an Accept nobody admitted to.
2. Among ties, take the cheap fix first. A configuration change that collapses a 6 today beats a migration that collapses a different 6 next quarter. Early wins also buy credibility for the slower work.
3. Prefer fixes that clear multiple rows. Some controls are broad-spectrum. Moving a flow to key-authenticated SFTP can simultaneously retire an eavesdropping row, a guessing row, and an impersonation row. When one action zeroes three risks, the register should say so — that is how you justify the bigger projects.

Every row ends in one of four decisions, and the vocabulary is worth using precisely. Mitigate: reduce likelihood or impact with a control. Accept: consciously live with it. This is legitimate for low scores and for exceptions with no current fix, but only with a named accepter and a revisit date. Avoid: eliminate the risk by retiring the flow. The census regularly reveals flows nobody needs, and deleting one is the only fix with negative cost. Transfer: shift consequences contractually, through insurance or by moving an obligation to a party better equipped to carry it. This is real, but rarer than the other three in transfer work. Avoid is also the only decision that makes the register shorter.

Keeping It Alive

A risk register decays the way its underlying estate changes — quietly. Three habits keep it true. Review on triggers: any new flow, new partner, protocol change, or security incident reopens the affected rows. An incident that was not on the register at all is the most valuable finding there is. It means the naming step has a blind spot. Review on schedule: a standing calendar slot, paired with the census refresh, catches the drift that triggers miss. Closed rows move to a "resolved" section rather than vanishing, so the register accumulates proof of progress. Keep the artifacts joined: census, register, and the per-flow threat models from earlier in this series reference each other. When one changes, the neighbors get a glance. Left alone, a register does not go wrong. It goes green.

And that closes the loop this series opened. You started by learning what attackers want. You now hold a page that says, for your own estate, what they would try, how much it would cost you, and what you are doing about it. It puts all that in an order you can defend. That page is threat modeling grown up: not fear, and not paperwork, but a short list of decisions with names on them.

Frequently Asked Questions