Risk Management Policy
Governs how Finaisse identifies, assesses, treats, and accepts security and privacy risk. Subordinate to the Information Security Policy.
| Policy owner | Security & Infrastructure Owner (Sekhar Prakash) |
| Applies to | All Finaisse systems, data, and third parties |
| Effective | 2026-08-27 (v0.1 draft) |
| Review cadence | Annual + at each quarterly posture review |
| Classification | Internal-confidential |
| SOC 2 / ISO | CC3.1–CC3.4 · ISO 27001 cl. 6.1, A.5.7 |
1. Purpose
Establish a consistent, documented method for identifying security and privacy risks to Finaisse and its customers' data, assessing them, and deciding how each is treated — so that remediation effort is prioritised by risk, not by whoever raises it loudest.
2. Risk methodology
- Identification — risks are surfaced through the assessment lenses in Coverage & Methodology (manual review, SCA, secret/IaC/image scanning) and — 🎯 Target — CI-gated scanning, SAST/DAST, and an independent penetration test (F-24, F-31).
- Assessment — each risk is rated by likelihood × impact, weighted by data sensitivity (Restricted data raises impact) and the tenant/identity boundary.
- Severity — expressed on the finding scale: P0 (exploitable now / ≤7d), P1 (high / ≤30d), P2 (real weakness / ≤90d).
3. Risk register
- All assessed risks are recorded in the Risk Register, and their exploited/observed instances in the Findings Register as tracked GitHub issues.
- Each risk carries an owner, a treatment, and a review date.
- 🎯 Target — populate the risk register from the current findings and STP/ICFR + AI-egress exposure, and review it at each quarterly posture review (owner: Security & Infrastructure Owner).
4. Risk treatment
Each risk is treated by one of:
- Mitigate — implement or strengthen a control (the default; tracked to closure against its severity SLA).
- Accept — retain the risk with documented rationale and an expiry date, approved by the Security & Infrastructure Owner. Recorded in the Statement of Applicability and, where relevant, the AWS Production Gate.
- Transfer — e.g. via a subprocessor contract or insurance (Vendor & Subprocessor Risk Policy).
- Avoid — remove the activity or data that creates the risk (e.g. keeping card PAN out of scope).
5. Risk acceptance
Risk acceptance is a deliberate, recorded decision — never a silent gap. Acceptances require owner approval, a rationale, and an expiry at which the risk is re-evaluated. No P0 risk may be accepted at production go-live (AWS Production Gate).
6. Roles
| Role | Responsibility |
|---|---|
| Security & Infrastructure Owner | Owns the methodology, approves acceptances, chairs the quarterly review |
| Engineering | Identifies risks in design/review; implements mitigations |
7. Review
Reviewed annually and at each quarterly posture review; the methodology is adjusted as the programme matures (e.g. when a formal risk-scoring rubric or GRC tooling is adopted).
Revision history
| Version | Date | Author | Change |
|---|---|---|---|
| 0.1 | 2026-08-27 | Security & Infrastructure Owner | Initial draft |