> ## Documentation Index > Fetch the complete documentation index at: https://course.pokesignal.io/llms.txt > Use this file to discover all available pages before exploring further. # 5.3 · Match Risks to Controls > Build a small register that gives each operating risk a fitting prevention, response, trigger, owner, and review date. If the primary sales venue became unavailable tomorrow, what would stop? Open orders, payout visibility, listings, or buyer communication might be affected. Selling inventory faster would not restore access. It addresses a different risk. That distinction is the purpose of a risk register. It prevents one sensible idea—more cash, faster turns, harder work, a second account—from being presented as the answer to every failure mode. ## Test whether the control fits For each risk, name the exposure before choosing the control. Then ask what the control actually changes: * **Probability:** does it make the event less likely? * **Exposure:** does it reduce the money, inventory, workload, or dependency present when it happens? * **Detection:** does it reveal the event or mismatch sooner? * **Recovery:** does it make the response faster, cheaper, or more reliable? Separate prevention from response. A position cap can reduce inventory exposure before a price move; it does not tell the business what to do after its exit limit is breached. Preserving records may help an investigation; it does not prevent a platform interruption or guarantee a favorable decision. The control does not need to remove the risk. It needs a defensible mechanism and a written point at which someone acts. ## Build the register around real dependencies Use a small number of material risks. The examples below show the required logic; replace every trigger and scope with the operation's own evidence. | Risk and exposure | Prevention and what it changes | Trigger and response | Owner and review | | ------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- | | Platform or service interruption: orders, records, payouts, or listings depend on one service | Keep transaction, inventory, and sourcing records; test a genuinely distinct venue. This improves recovery and reduces concentration, not outage probability. | If required access is lost or an open promise is at risk: pause new commitments, reconcile orders and cash, preserve notices, and communicate under [Chapter 4.4](/chapters/4-4-fulfillment-and-the-customer-promise). | Owner: \_\_\_; next review: \_\_\_ | | Fraud, authenticity, or material transaction mismatch: cash, stock, or customer outcome is exposed before evidence agrees | Use written identity, payment, provenance, condition, and inspection checkpoints; cap one-counterparty exposure. This improves detection and limits loss. | On an evidence mismatch, failed inspection, or missing payment or item: stop the next reversible step, quarantine affected stock, preserve evidence, and use the governing procedure. | Owner: \_\_\_; escalation: \_\_\_; review: \_\_\_ | | Inventory repricing or illiquidity: value changes or the buyer pool cannot absorb the position on schedule | Apply the [Chapter 5.2](/chapters/5-2-bankroll-discipline) allocation boundary, write the exit condition, and track age. This limits amount and duration exposed. | When a written price, age, contribution, or capital-use limit is breached: stop adding exposure and reopen the [Chapter 2.4](/chapters/2-4-selling-is-a-math-problem) exit and capital decisions. | Owner: \_\_\_; review: \_\_\_ | | Concentration: one venue, product, counterparty, customer segment, or owner carries too much of one defined exposure | Measure one dependency on one basis and date; set a maximum; test only an operationally distinct alternative. This limits one failure's reach. | When the share exceeds the maximum or enters a warning state: stop adding exposure and execute the prewritten reduction or test. | Owner: \_\_\_; maximum: \_\_\_; review: \_\_\_ | | Demand slowdown: demand falls against the operation's comparable history while commitments continue | Use the business's own baseline, preserve the [Chapter 5.2](/chapters/5-2-bankroll-discipline) cash boundary, and prewrite the first commitment to change. | When the chosen demand or cash measure crosses \_\_\_: make the written intake, spending, or capacity change and schedule a review. | Owner: \_\_\_; review: \_\_\_ | | Owner-capacity interruption: one person's time, knowledge, or authority is required for a critical stage | Document the minimum process and name coverage or a deliberate pause. This limits one-person dependency and new commitments. | When the next intake, fulfillment, or response window cannot be met—or workload crosses \_\_\_—invoke coverage or pause, update promises, and send a recurring queue to [Chapter 6.1](/chapters/6-1-systems-before-scale). | Owner: \_\_\_; backup/pause: \_\_\_; review: \_\_\_ | For transaction risk, a questionnaire, photograph, sample, or prior history can inform a written check; none proves that a counterparty or whole lot is safe. Name the mismatch that stops work and the evidence that releases it. ## Measure concentration on one basis Concentration becomes usable when the denominator is explicit: **Dependency share = exposure tied to one dependency ÷ total relevant exposure** Choose one basis whose parts can be added cleanly—completed orders, inventory acquisition cost, open payments, sourcing spend, or critical workflow hours—and one period or measurement date. The amount tied to one dependency must be part of the total and cannot exceed it. The total must be positive; if it is zero, the share is *not applicable*, not zero. Suppose an invented shop completed 90 orders in eight weeks and 72 used one venue. Its dependency share on the completed-order basis is `72 ÷ 90 = 80%`. That describes the concentration; it does not make 80% a course limit or prove that the venue is unsafe. Choose the maximum and response from the continuity your operation needs. Faster sale or a smaller position belongs in the inventory row because it can reduce the amount or time exposed. Cash can absorb a loss but does not prevent the event. Use neither as a substitute for the other controls in the register. ## Use current rules only where they apply When a response depends on a platform, payment, authentication, privacy, claim, or appeal rule, check the current official procedure for the actual account, transaction, and jurisdiction. Record its source, date, and scope. Until verified, do not assume records guarantee reinstatement, exports are permitted, a visual clue proves authenticity, or contact details may be reused. ## Finish the register Copy the table into your register. Keep only risks that can materially interrupt the next review period, replace every illustrative scope and trigger with your own evidence, and add any material risk that is missing. For each row, record which of probability, exposure, detection, or recovery the prevention changes, then give the response a trigger, owner, next action, and date. Attach the source and check date to any row that depends on a current external procedure. **Register period:** \_\_\_ through \_\_\_ **Full review date:** \_\_\_ **Reopen immediately after:** \_\_\_