Security Standards & Methodology

How the Finaisse security posture is defined, scored, and maintained. For current status see the Security Dashboard; for the worklist see the Findings register.

Target state: Enterprise SaaS Financial Platform Security Baseline — a defense-in-depth posture that can survive enterprise customer security reviews, SOC 2 / ISO 27001 audits, and 300-question security questionnaires.

Owner	Classification	Version	Effective	Next review	Status
Sekhar Prakash	Internal	1.0	2026-06-24	2026-11-27	Active

Scope & asset criticality

Factor	Assessment
Business criticality	Very High
Internet exposure	High
Data sensitivity	High (customer financial data)
Regulatory expectations	SOC 2 (target) · India DPDP · ISO 27001 likely · customer audits
Attack surface	Large (multi-service API, file uploads, email ingestion, AI agents, admin portal)
Multi-tenant risk	High
Supply-chain risk	High
Cloud misconfiguration risk	High
Insider-threat risk	Medium
Availability requirement	High

Open scoping decisions: see Open Decisions below.

Open decisions (owner input needed)

• Choices only the security/infra owner (Sekhar Prakash) can make — distinct from the engineering work in the findings register.
• Each gates or shapes a tracked item but needs a cost / vendor / scope call first.
• Listed here so they don't stay buried inside issue bodies.

Decision	Why it's a decision (not just work)	Gates / relates to
SAST tooling — GitHub Advanced Security (CodeQL) vs OSS Semgrep	GHAS is paid on private repos; Semgrep is free but self-run. ⚠️ Tested 2026-09-22, and it is not a like-for-like choice: Semgrep OSS does not cover the rule families CodeQL reported. p/javascript ships 74 rules total, with no rule for insecure randomness, log injection, ReDoS or weak hashing, and its only SSRF/path-traversal rules are Express-specific (this stack is Elysia); a purpose-built file containing four of the reported vulnerability classes returned 0 findings, and its one SSRF rule timed out against blitz. The deep interprocedural dataflow is Semgrep Pro, also paid — so the real choice is which paid tool, or accept partial coverage. Worth evaluating: SonarQube Community (free, self-hosted, covers TypeScript and C# — relevant since 49 of the 169 findings are csharp), targeted ESLint security rules, or GHAS scoped to blitz alone. ⚠️ The larger gap is that no scanner runs in CI at all — a one-off scan is not a control under CC7.1, and the free GitHub assessment is rate-limited to once per ~90 days (next available 2026-12-20).	SAST lens (coverage); fin-infra#40; blitz#1548
Secret scanning / push protection — GHAS native vs OSS gitleaks	Same GHAS cost question; gitleaks (already run ad-hoc) is free in CI.	fin-infra#40; F-34/F-35
Penetration-test vendor, budget & timing	Which firm, what scope, and the go-live gate date — a procurement decision.	fin-infra#39 (F-24)
SSO / SAML provider for enterprise tenants	Tool/vendor choice (Okta / Entra / WorkOS / etc.).	Domain 4; blitz#1007 (F-23)
Compliance target & timeline	Confirm SOC 2 as the formal audit target and target date (ISO 27001? DPDP baseline scope?).	Domain 15
PCI-DSS in / out of scope	Determines whether card-data controls apply at all.	Scope
AWS production go-live date & hard gate	Sets the deadline the AWS gate must be met by.	Go-live

Resolve these at each posture review; record the decision (and date) here when made, then the related issue becomes pure engineering work.

Data classification

Class	Examples	Baseline handling
Public	Marketing content, public docs	No restriction
Internal	Product documentation, runbooks	Authenticated access
Confidential	Customer configuration, tenant metadata	Encrypted, access-controlled, audited
Restricted	Financial transactions, journals, invoices, reconciliations, PII	Encrypt at rest + in transit, strict least-privilege, full audit trail, tenant-isolated, retention/deletion policy

Data lifecycle to govern for each class: creation → processing → storage → archival → deletion.

Security principles

1. Zero Trust by default
2. Defense in depth
3. Least-privilege access
4. Secure by design
5. Immutable auditability
6. Tenant isolation
7. Continuous verification
8. Automated security controls
9. Rapid detection & response
10. Data-centric security

Risk-prioritization rubric & remediation SLAs

Severity is impact × reachability, weighted for a financial multi-tenant platform.

Each finding is scored across:

• exposure
• data sensitivity
• exploitability
• blast radius / lateral movement
• financial-fraud impact
• regulatory impact
• runtime context (prod/staging/dev)
• attack surface
• detection/response coverage
• compensating controls
• remediation speed

A high-priority issue is one that is internet-facing, exploitable, hits Restricted data or the tenant boundary, and is already deployed.

Severity	Definition	SLA
P0	Exploitable now, hits Restricted data or the cross-tenant boundary, low effort	≤ 7 days; actively exploited → immediate
P1	High impact with a precondition, or on the AWS go-live path	≤ 30 days
P2	Real weakness, limited reach or strong compensating control	≤ 90 days

How this posture is maintained

• Standards (this section) reviewed each quarter and on major architecture change.
• Findings register (/security/findings) is the live worklist; every finding is a GitHub issue carrying the security label + the SLA above, tracked on the Finboard project.
• Maturity ratings (dashboard + domains) are re-scored each review from the open findings.
• Control implementations live as code in blitz, blitz-ui, fin-infra; this site links to them rather than duplicating.
• Methodology note: iteration 1 (2026-06-24) is a read-only code review, not a penetration test. Findings tagged needs runtime confirmation must be validated dynamically before closure; independent external validation is itself a tracked gap (fin-infra#39).

Revision history

Version	Date	Author	Change
1.0	2026-06-24	Sekhar Prakash	Standards, scope, data classification, and security principles established.

Finaisse Internal — Confidential. Not for external distribution.