CBSRM · Security & onboarding

Institution-first access. Evidence before release.

The new microfinance SaaS is being developed with server-enforced institution and branch boundaries. Production security must be demonstrated on the deployed service, not inferred from a login screen or functional test counts.

01

Institution and branch permissions

Separate institution workspaces with multiple branches, users and explicitly scoped roles. Cross-institution and nested branch-data paths must be independently verified.

02

Approved support access

No routine partner or CBSRM support access to financial, borrower or private working data. Temporary grants require institution approval, scope, expiry, revocation and an audit record.

03

Country-approved hosting

Choose the approved hosting country and operating controls with each institution. Country configuration, currency and interface language are separate choices.

The production onboarding gate.

Agree the institutional identity policy and approval process, verify the hosting boundary, then evaluate scoped data import and risk workflows against documented acceptance cases.

  • Invitation-only institution access; enforced MFA for every user, sessions and revocation. Institutional SSO is activated only after the identity provider and MFA enforcement are tested.
  • Tenant and branch isolation across views, reports, jobs and exports.
  • Approved support grants with current-rights checks and audit evidence.
  • Managed database access, encryption, secrets and tested recovery.
  • Secure source permission, schema integrity and version-specific conformance.
  • Independent deployment review and explicit residual dependencies.

Define a reviewable pilot boundary.

Use approved sample inputs and a named review owner. Confirm the country, identity policy, data source and acceptance measures before enabling institution access.

Discuss onboarding →