Finaisse Policy Library (ISMS)

The Finaisse Information Security Management System (ISMS) policy set. These are the governing documents behind the security posture and the system description — the "documented process" half of SOC 2 that technical controls alone do not satisfy.

Status: initial draft — target-state with dated controls

Finaisse is pre-production. These policies are written as the intended steady state, and controls not yet fully operating are marked 🎯 Target with an owner and expected date. That is deliberate and audit-honest: a SOC 2 Type II examination tests whether controls operated over a window, so a policy that claims a control already runs when it does not is worse than one that states the target and date. As each control lands, remove its 🎯 marker and record the change in the document's revision history.

ISMS owner	Sekhar Prakash — Security & Infrastructure
Applies to	All Finaisse personnel, contractors, systems, and the Finaisse platform
Review cadence	Annual, and on major architecture or organisational change
Current stage	Pre-production; staging on Railway, AWS production being built

Policies

#	Policy	Covers	SOC 2 (TSC)
1	Information Security Policy	Master policy — ISMS scope, governance, principles	CC1, CC2, CC3, CC5
2	Access Control Policy	Identity, authentication, authorisation, reviews	CC6.1–6.3
3	Change Management Policy	Code/infra change, review, deployment, release	CC8.1
4	Incident Response Policy	Detection, response, escalation, notification	CC7.3–7.5
5	Business Continuity & Disaster Recovery Policy	Backups, RTO/RPO, recovery, resilience	A1.2, A1.3
6	Vendor & Subprocessor Risk Policy	Third-party assessment, subprocessor register	CC9.2
7	Secure Development Lifecycle Policy	Secure design, testing, vulnerability management	CC7.1, CC8.1
8	Data Classification & Retention Policy	Classification, handling, retention, deletion	C1, CC6.5, P
9	Acceptable Use Policy	Personnel use of systems, endpoints, credentials	CC1.4, CC6.7
10	Risk Management Policy	Risk identification, assessment, treatment, acceptance	CC3.1–3.4
11	Cryptography & Key Management Policy	Encryption in transit/at rest, key & secret lifecycle	CC6.1, CC6.7
12	Human Resources Security & Awareness Policy	Personnel lifecycle, security awareness training	CC1.4, CC2.2
13	Privacy & Data Protection Policy	Lawful processing, data-subject rights, breach	P, C1
14	Asset Management Policy	Asset inventory, ownership, disposal	CC6.1
15	Logging & Monitoring Policy	Security logging, monitoring, retention	CC7.2, CC7.3
16	Physical & Environmental Security Policy	Hosting (cloud-inherited), endpoints	A.7
17	Code of Conduct & Ethics	Professional & ethical standards	CC1.1
18	Mobile Device & Remote Working Policy	Endpoint & remote-access security	A.6.7

Ownership

Each policy is owned by the accountable function, and the ISMS is approved at senior-management level (demonstrating SOC 2 CC1 / ISO clause 5 commitment):

• Security & Infrastructure Owner (Sekhar) — technical security policies (1–4, 7, 10, 11, 14, 15, 18).
• COO (Payeli) — people, privacy, and operational policies (5, 9, 12, 13, 16, 17).
• Approver — COO (Payeli) as executive sponsor; CEO (Kris) for management commitment on the master policy.

The governance map is the ISMS Scope & Framework.

ISO 27001 mandatory ISMS documents (distinct from policies; required only for ISO certification, not SOC 2): ISMS scope statement, security objectives, risk assessment methodology (covered by the Risk Management Policy), Statement of Applicability ✅, internal audit programme, management review records. These sit under the ISMS governance layer — see the ISMS Scope & Framework and System Description — and are placeholders until ISO is pursued.

How these relate to the rest of the docs

• Security domains and coverage describe what we protect and how well; these policies state the rules and responsibilities that govern it.
• Platform Operations holds the operational procedures a policy points to (e.g. the Incident Response Policy sets the rules; Run & Operate is the step-by-step).
• Findings register tracks the engineering work to close gaps these policies mark as 🎯 Target.

Conventions

• 🎯 Target — a control this policy commits to that is not yet fully operating; carries an owner + expected date.
• Owner / Approver — functional roles; where a named person is required today, that is the ISMS owner (Sekhar Prakash) until the team grows.
• Each policy carries a revision history; material changes require ISMS-owner approval.

Access & handling

Internal-confidential. Restricted to members of the finaisse-org GitHub organization. These are governing documents, not customer-shareable marketing — a customer trust summary is derived separately.