The Risk Register: Fields, Risk Owners, and Keeping It Audit-Ready

A risk register is the single, continuously updated log of every identified risk on a project — what each risk is, how likely and how damaging it could be, who owns it, what the response plan is, and its current status. It is the one place anyone joining or reviewing a project should go to understand its risk picture. On the PK0-005 exam, the risk register shows up as the answer to “where would you find this risk information,” so knowing its standard fields and the roles attached to it matters as much as knowing the definition.

What the risk register is for

Risk identification happens throughout a project — in planning workshops, status meetings, retrospectives, and hallway conversations. Without a central artifact, those findings evaporate. The register captures them in one structured document (often a spreadsheet or a tab in the project management tool) so that risks can be scored, ranked, assigned, and tracked to closure.

Two properties define a healthy register:

• It is a living document. The version from the planning phase is a starting point, not a deliverable. New risks get added the moment they are identified, and existing entries get updated as probability, impact, or status changes.
• It is the authoritative source. If a stakeholder, sponsor, or incoming project manager asks about the project’s risks, the answer should come from the register — not from memory or scattered meeting notes. A mid-stream handover is the classic test: the new project manager should be able to open the register and see every open risk, its owner, and its response plan without interviewing the whole team.

Core fields of a well-maintained register

CompTIA expects you to recognize which elements belong in a register. The standard set:

• Risk ID — a unique identifier so risks can be referenced unambiguously in meetings and reports.
• Risk description — a clear statement of the uncertain event and its potential consequence (“Vendor may miss the firmware delivery date, delaying integration testing”).
• Probability — how likely the risk is to occur, usually rated on a simple scale (1–5 or low/medium/high).
• Impact — how severe the consequence would be if it did occur, rated on the same kind of scale.
• Risk score — typically probability multiplied by impact, used to rank risks; the scoring mechanics are covered in qualitative risk analysis.
• Risk owner — the named individual accountable for monitoring and responding to the risk.
• Response plan — the chosen strategy (avoid, mitigate, transfer, accept) and the concrete actions behind it.
• Triggers — the warning signs that indicate the risk is about to occur or has occurred.
• Status — open, in progress, occurred (converted to an issue), or closed.

Fields that do not belong in the register are a favorite exam distractor: individual team members’ salaries, the full project budget breakdown, or general meeting minutes. If an element isn’t about tracking an uncertainty, it lives in a different artifact.

What a risk owner actually does

When a risk is logged, the project manager assigns a risk owner — a specific person, not a team or a role placeholder. The owner’s responsibilities:

• Watch the triggers. The owner monitors the early-warning indicators for their risk so the team isn’t surprised.
• Maintain the entry. If the probability rises or the potential impact grows, the owner updates the register so the ranking stays honest.
• Execute the response. If the risk materializes, the owner is the one who implements the planned response and escalates if it isn’t working.

Note the distinction: the project manager owns the risk management process; the risk owner owns an individual risk. The exam probes this by describing a person assigned to monitor one risk’s triggers and carry out its response plan, then asking what that person is called.

Keeping it current — reviews and audits

Two related but distinct activities keep the register trustworthy:

Activity	Who performs it	What it examines
Risk review (reassessment)	Project team, in regular status/risk meetings	Individual risks: are scores still accurate, any new risks, can any be closed
Risk audit	Independent reviewer outside the team	The process itself: were responses effective, is the register up to date, is risk management being followed as planned

A risk review is routine, internal, and focused on the content of the register. A risk audit is periodic, independent, and focused on the effectiveness of the whole risk management process — it asks whether the responses actually worked and whether the team is practicing what the risk management plan preaches. When an exam scenario describes an outside party evaluating response effectiveness and process compliance midway through a project, that is a risk audit, not a review.

Keeping the register “audit-ready” simply means the discipline holds up under that independent examination: every open risk has a current score, a named owner, a documented response, and a status that reflects reality.

How the PK0-005 exam tests this

• A “where do I find it” scenario: a new or incoming project manager needs a single up-to-date log of risks, owners, responses, and statuses — the answer is the risk register, distinguished from the issue log, stakeholder register, or project charter.
• A role-identification scenario: someone is assigned to monitor a specific risk’s triggers and execute its response plan — the exam wants “risk owner,” not project manager or sponsor.
• A “select all that apply” question listing candidate register fields — you must pick legitimate fields (description, probability, impact, owner, response, status, triggers) and reject plausible-sounding intruders.
• A process-assurance scenario: an independent party checks response effectiveness and process compliance mid-project — the answer is a risk audit.

Risk artifacts sit in the Project Management Concepts domain — the full PK0-005 study guide covers that domain’s weight and the rest of the exam blueprint. Field-recognition items like these become easy marks after a few rounds of Project+ practice questions.

Quick reference

• The risk register is the single living log of all identified risks — the authoritative source during handovers and reviews.
• Standard fields: ID, description, probability, impact, score, owner, response plan, triggers, status.
• Risk score is typically probability × impact and drives ranking.
• A risk owner is a named individual who monitors triggers, keeps the entry current, and executes the response plan.
• The project manager owns the process; risk owners own individual risks.
• Risk review = internal, routine reassessment of risks; risk audit = independent examination of response effectiveness and process compliance.
• When a risk occurs, it becomes an issue and moves to issue management — the register entry is updated, not deleted.