How to Write a Risk Assessment for Consulting Work

A risk assessment is a decision document. It should help a responsible person decide whether work can proceed, what restrictions apply, and which actions must happen first. If it is only a list of scary words and colored scores, it will not guide the work.

This guide uses a consulting scenario: a team is conducting a strategy review engagement that includes executive interviews, analysis of client records, a recommendations report and a client presentation. The main risks are not falling objects or machinery; they are confidentiality breach, unsupported recommendations, scope drift, system access failure and poor handoff. Adapt the method to your industry and jurisdiction.

Define the activity and what is affected

Begin with a tight activity statement. "Client project" is too broad. "Conduct discovery interviews and prepare recommendations report for the strategy review engagement" is usable.

Draft language:

Activity: Conduct discovery interviews, analyze approved client records and prepare the strategy review recommendations report. People and assets affected: client sponsor, interviewees, consulting project team, subcontracted analyst, confidential client records, project repository, delivery schedule and final recommendations report. Assessment limits: this assessment covers consulting delivery and information handling; employment, legal and specialist technical advice are routed to the appropriate reviewer.

Ready.gov's business impact analysis guidance is continuity-focused, but its logic is helpful: identify effects of disruption and gather information needed for recovery decisions (Ready.gov business impact analysis). In a risk assessment, you similarly identify what matters before you judge exposure.

Review criteria:

• The activity has a start and finish.
• Affected people, services, information and assets are named.
• Boundaries and exclusions are stated.
• Specialist matters have a review route.

Identify hazards or risk events

For office and consulting work, "hazard" may sound too physical, but the same discipline applies: describe credible events, causes and consequences.

Example entries:

Avoid vague entries like "data risk" or "quality risk." The reviewer needs to see what could happen and why. If a risk event cannot be connected to a cause or consequence, it may be too vague for action.

Record existing controls

Existing controls are things already operating. They might include access permissions, confidentiality briefing, approved folder structure, evidence-table review, scope change process, secure client portal, named engagement lead and backup reviewer.

Draft language:

Existing controls: all project team members complete confidentiality briefing before access; project repository permissions are limited to the engagement team; recommendations must be linked to the evidence table before senior review; scope changes require engagement lead approval; client updates use the approved sponsor contact list.

For information-security risks, NIST SP 800-30 Revision 1 provides an assessment framework covering the risks faced by information systems and organizations. Its US federal guidance is relevant to the client-file example, not a substitute for assessing commercial scope decisions. Record the disclosure event, the weakness that could enable it and the effect on the client. Verify that the stated controls actually exist: a future folder audit is not an existing control until someone performs it and records the result.

Review criteria:

• Controls are current and evidenced.
• Each control maps to a risk event.
• Planned improvements are not counted as existing controls.
• The owner of each control is clear.
• Controls do not create new unmanaged risks.

Evaluate residual risk

Residual risk is what remains after existing controls. You can use a simple low, medium, high method or a numeric matrix, but define the method before scoring. A score without reasoning is decoration.

Draft language:

Residual risk: confidentiality breach remains medium because folder permissions reduce access risk, but interview notes are still handled by multiple roles and may be copied into drafts. Further restriction is required before subcontractor access is granted.

Then explain the decision:

The responsible decision maker should review whether the remaining exposure is acceptable. In consulting, that may be the engagement lead, practice director, client sponsor or operations owner, depending on the risk and contract.

Assign actions and owners

Actions close the gap between current risk and acceptable risk. Each action needs an owner, due point, evidence and status. "Be careful" is not an action.

Draft language:

Action: engagement lead to approve subcontractor access before any interview notes are shared. Due: before subcontractor work starts. Evidence: access approval note saved in project repository. Owner: engagement lead.

Action table:

Operational review criteria:

• Actions address specific residual risks.
• Owners have authority to complete them.
• Due points relate to the work sequence.
• Evidence proves completion.
• High or unacceptable residual risks stop or restrict work until resolved.

Look for actions that are actually decisions in disguise. "Decide whether the subcontractor can access interview notes" is not the same as "limit subcontractor access to sanitized extracts." If the decision is still open, name the decision maker and due point. If the decision has been made, write the control as an action someone can complete and evidence. This keeps the assessment from becoming a meeting agenda with risk scores attached.

Review, approve and revisit

Approval is not a signature at the bottom of an unread table. The approver should see the activity, main risk events, existing controls, residual risks and actions. They should be able to approve, approve with restrictions, or require revision.

Draft language:

Approval: The engagement lead reviews residual risks and authorizes work to proceed only after actions marked "before start" are complete. Reassessment is required after scope change, confidentiality incident, repository access change, client complaint, missed review gate or replacement of the engagement lead.

The consulting risk assessment template provides an editable Word structure for activity and people affected, hazards and existing controls, evaluation and further action, approval and review. Use it as a working draft, then replace the example content with your project's facts, records and decision roles.

Final review checklist:

• Activity and limits are clear.
• Risk events are credible and specific.
• Existing controls are real and evidenced.
• Residual risk is explained.
• Actions have owners, due points and proof.
• Approval is active and recorded.
• Review triggers reflect how the work changes.

One last practical test is to read the assessment against tomorrow's calendar. If interviews, analysis reviews and client updates are already scheduled, the risk assessment should say which of those activities can continue, which need a completed action first, and who will tell affected people about restrictions. That turns the assessment from a static document into a usable operating decision.