A Practical Risk Assessment for Your Transfer Estate

"Risk assessment" is a phrase that smells of consultants, binders, and meetings that produce more meetings. Underneath the ceremony 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, multiply, and 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: building on your flow inventory, naming risks so they can be scored, anchored 1-to-3 scales for likelihood and impact, the matrix that turns scores into priorities, 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.

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: estimating each one's likelihood (how plausibly it happens to you) and impact (how bad the day is when it does), and using 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 — which, in practice, 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, and the estate's most dangerous flows are usually the undocumented ones. Which is why the method starts where it starts.

It is also worth knowing that this document has an audience beyond you. Security questionnaires from customers, due-diligence reviews, insurance applications, and audit frameworks all eventually ask some version of "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.

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, and 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, and 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: what data it carries (and how sensitive), what protocol it uses (encrypted or not), 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. Automation attempts this continuously against everything reachable (credential guessing on any internet-facing login), or it 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. Regulatory notification territory (personal, financial, or health data exposed), breach of a contractual obligation to a partner, or serious operational harm — 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: the sensitivity of the data in the flow, the business weight of the process depending on it, and the blast radius — whether the event stays contained to one folder and one partner or opens onto the wider network. A risk that hands an attacker a foothold (a compromised transfer host, an exposed admin interface) scores 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, 3 to 4 get scheduled, 1 to 2 get watched:

A note on humility: 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 obviously-urgent from the obviously-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.

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 3 (your logs show the attempts tonight), impact 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.

Notice what the numbers just did: they 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.

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 — 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 — real, but rarer than the other three in transfer work.

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, because 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 — and 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.

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 — 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