Risk Assessment and Management Policy template (SOC 2)

1. Purpose

This policy establishes how Northwind Cloud Inc identifies, analyses, treats and monitors the risks that could prevent it from meeting its security, availability and business objectives for Northwind. It gives Northwind Cloud Inc a consistent way to decide which risks matter, what to do about them, who may accept them, and how to show that decisions were made and followed through; every control should trace to a risk in the register, and every risk should have an owner and a decision.

2. Scope

This policy applies to all risks to the confidentiality, integrity and availability of Northwind Cloud Inc information and systems, whether arising from technology, people, processes, vendors, physical environments, legal change or fraud. It covers Northwind and its infrastructure in AWS and Vercel, corporate systems, data held by vendors such as Supabase, Stripe, Datadog and Slack and the personnel (headcount band 11-50) who operate them, and binds Executive Management, the Security Owner, system owners and everyone who owns a risk or treatment action. Risks are scored on likelihood and impact using the scales below; the score is likelihood multiplied by impact, and the rating sets the required response.

3. Roles and Responsibilities

• Executive Management approves this policy and the risk appetite, reviews the risk register at least quarterly, alone may accept Critical risks, funds treatment plans, and considers assessment results when setting company objectives.
• Security Owner (Dana Whitfield, CTO) owns this policy and the risk register, leads annual and triggered assessments, facilitates scoring, tracks treatment actions to closure, maintains the risk-to-control mapping, and reports risk status to Executive Management.
• Engineering identifies technical threats and vulnerabilities affecting Northwind and its infrastructure on AWS and Vercel, owns technical treatment actions, provides evidence that controls operate, and raises new risks from architecture and vendor changes.
• People Operations identifies risks from hiring, role changes, departures, training gaps and insider threat, owns treatment actions in those areas, and reflects risk responsibilities in role descriptions.
• All Personnel raise risks they observe to their manager or security@northwindcloud.example, complete assigned treatment actions on time, and cooperate with assessments.

4. Policy Statements

• 4.1 Northwind Cloud Inc conducts a formal risk assessment at least annually and after triggers including a SEV1 or SEV2 incident, a significant change to Northwind or its infrastructure, adoption or loss of a Tier 1 vendor, entry into a new market or regulatory regime, a material organisational change, or a failed control test; triggered assessments may be limited to the affected area.
• 4.2 Every assessment identifies assets and owners, threats and vulnerabilities, existing controls, and likelihood and impact on the Section 2 scales, considering external attack, internal misuse, error, vendor failure, environmental events, legal change and fraud, including misuse of privileged access and manipulation of financial or customer records.
• 4.3 Northwind Cloud Inc maintains a single risk register recording for each risk an identifier, description, affected assets and objectives, owner, inherent and residual likelihood, impact and score, existing controls, chosen treatment, actions with owners and due dates, acceptance decisions with approver and expiry, and date of last review.
• 4.4 Each risk is treated by mitigating, transferring, avoiding or accepting it, and the choice and rationale are recorded in the register.
• 4.5 Residual risk is accepted only by the authority in Section 2: Critical by Executive Management, High by the Security Owner with a member of Executive Management, Moderate by the Security Owner, Low by the system owner. Acceptances are written, state the reason and any conditions, and expire within 12 months, after which the risk is re-approved or treated.
• 4.6 Northwind Cloud Inc's risk appetite, approved by Executive Management, is that no Critical risk is carried without an active treatment plan, no risk of exposing customer data or PII data is accepted at High or Critical, and risks to customer availability commitments are treated before risks affecting only internal convenience.
• 4.7 Every risk has one named owner accountable for the treatment decision and for keeping the entry current; treatment actions have owners and due dates in the ticketing system, and overdue actions on High and Critical risks are reported to Executive Management at the next quarterly review.
• 4.8 The Security Owner maintains a mapping from each risk to the policies and controls that treat it and to the applicable Trust Services Criteria, so that the control set can be shown to follow from assessed risks and gaps are visible.
• 4.9 Control operation is monitored through defined evidence: access reviews, vulnerability scans, backup and restore tests, incident metrics, vendor reviews and training completion. When monitoring shows a control has failed, the related risk is re-scored and, if it reaches High or Critical, a triggered assessment is opened.
• 4.10 Risks from vendors, including Supabase, Stripe, Datadog and Slack, and from platform dependencies on AWS and Vercel are assessed under this policy using information gathered under the Vendor and Third-Party Risk Management Policy, with concentration and continuity risks recorded and owned.
• 4.11 The Security Owner reports to Executive Management at least quarterly on new and closed risks, rating changes, overdue actions, acceptances approaching expiry and control monitoring results; the review and its decisions are minuted.
• 4.12 Findings from internal reviews, external audits, penetration tests and post-incident reviews are entered in the register or linked to an existing risk within ten business days, so one prioritised action list exists.
• 4.13 At least annually, someone who does not own the register (a member of Executive Management, an internal reviewer or an external advisor) evaluates whether the assessment was complete, scores consistent and treatments carried out, and records the outcome.

5. Procedures

• 5.1 Annual planning. The Security Owner schedules the assessment, confirms scope with Executive Management, updates the asset inventory with Engineering and People Operations, gathers the incident log, vulnerability reports, vendor reviews, audit findings, monitoring results and changes to Northwind and applicable law, and invites system owners to workshops.
• 5.2 Identification. In workshops, the Security Owner walks through each asset group (production in AWS and Vercel, code and delivery in GitHub and GitHub Actions, identity and endpoints, corporate data, vendors, people and facilities) and records threats, vulnerabilities and existing controls, including fraud scenarios and ways a privileged user could bypass controls; new risks receive an identifier in the form RISK-NNN.
• 5.3 Scoring. Participants agree inherent likelihood and impact on the Section 2 scales, list existing controls and agree residual scores; the Security Owner challenges scores inconsistent with comparable risks or incident history and records the rationale.
• 5.4 Treatment planning. For each risk rated Moderate or above, the owner proposes treatment, actions, owners, due dates and expected residual rating within the timeframe for the rating; the Security Owner reviews plans for completeness and cost, and Executive Management approves plans for Critical risks and any plan needing budget.
• 5.5 Acceptance. Where acceptance is proposed, the Security Owner summarises the risk, controls, residual score and reason, obtains written approval from the authority in 4.5, records approver and expiry in the register and adds the expiry to the review calendar.
• 5.6 Register maintenance. The Security Owner updates the register within ten business days of any change: new risks from incidents, audits, vendor reviews or personnel reports; completed actions with evidence; re-scored risks; and expired acceptances. Each entry shows the date and author of its last change.
• 5.7 Quarterly review. The Security Owner reviews every High and Critical risk with its owner, confirms progress, re-scores where circumstances have changed, chases overdue actions, checks acceptances expiring next quarter, reviews monitoring evidence and prepares the report required by 4.11.
• 5.8 Triggered assessment. When a trigger in 4.1 occurs, the Security Owner opens a triggered assessment within five business days limited to the affected scope, follows 5.2 to 5.5, and reports to Executive Management within 30 days, or immediately if a Critical risk is found.
• 5.9 Control monitoring. Engineering, People Operations and the Security Owner collect the evidence in 4.9 on the cadence set in the relevant policy, record results against mapped risks and raise a ticket for any control not operating; the Security Owner reviews results monthly and re-scores affected risks.
• 5.10 Independent evaluation. Once a year the Security Owner arranges the evaluation required by 4.13, provides the register, treatment evidence and monitoring results, records findings as risks or actions and presents the evaluation to Executive Management.

6. Exceptions

Exceptions require written approval from Executive Management, a statement of the reason and compensating measures, and an expiry date no more than 12 months away, and are recorded in the risk register and reviewed at each annual policy review. No exception permits a Critical risk to be accepted by anyone other than Executive Management, or an acceptance to remain in force past its expiry without re-approval.

7. Enforcement

Failing to raise a known risk, failing to complete an assigned treatment action without an approved extension, accepting a risk without the required authority, or altering the register to conceal a risk or its status is a violation of this policy and may result in disciplinary action up to and including termination of employment or contract.

8. Review Cadence

The Security Owner reviews this policy on a annual basis and after any independent evaluation that identifies a weakness in the risk process, any SEV1 incident caused by an unidentified or mis-scored risk, and changes to Northwind Cloud Inc's objectives, regulatory obligations or scope of examination. Each review is approved by Priya Natarajan, CEO and recorded in Section 9.

9. Revision History