Access-Control Policy — Veloxis
Effective date: [to be set on first publication] Last revised: 2026-05-24 Owner: CA Krishna Gujarathi Review cadence: Quarterly user-list review + annual policy review
This policy defines who may access what inside the Veloxis Platform, how access is granted and revoked, and how access reviews are performed. It is the role-based-access-control (RBAC) reference for the Firm's Information Security Policy §2.
1. Roles
Veloxis defines five roles. Every user account belongs to exactly one role.
| Role | Description | Typical headcount in the Firm |
|---|---|---|
MANAGING_PARTNER |
Top-level role with administrative + audit-quality + AI-Advisor access | 1 |
PARTNER |
Engagement sign-off authority u/s 141 Companies Act, 2013 | 1-3 |
MANAGER |
Engagement review authority before partner sign-off | 1-5 |
SENIOR_ARTICLE / ARTICLE |
Preparer level; performs fieldwork | 3-15 |
CLIENT |
Client-portal access — limited to own engagement deliverables + upload tray | Per client engagement |
2. Permissions matrix (canonical)
R = read · W = write · S = sign-off · — = no access · O = own-engagement-only.
| Capability | MP | Partner | Manager | Article | Client |
|---|---|---|---|---|---|
| View list of engagements | R (all) | R (all) | R (assigned) | R (assigned) | R (own) |
| Create new engagement | W | W | — | — | — |
| Assign engagement team | W | W (own) | — | — | — |
| Upload TB / Daybook | W (all) | W (own) | W (assigned) | W (assigned) | — |
| Edit FS Grouping | W (all) | W (own) | W (assigned) | W (assigned) | — |
| Edit checklist items | W (all) | W (own) | W (assigned) | W (assigned) | — |
| Approve checklist items at "Reviewed" gate | W (all) | W (own) | W (assigned) | — | — |
| Sign-off final deliverable | S (all) | S (own) | — | — | — |
| Run Smart Check / Ask Tool | W (all) | W (own) | W (assigned) | W (assigned) | — |
| Run AI Advisor | W (all) | — | — | — | — |
| AI Tokenisation Preview + Allowlist | W (all) | W (own) | R (assigned) | — | — |
| Download signed reports | R (all) | R (own) | R (assigned) | R (assigned) | R (own engagement only) |
| Upload supporting documents | W (all) | W (own) | W (assigned) | W (assigned) | W (own engagement upload tray only) |
| User management | W | — | — | — | — |
| Firm settings / system config | W | — | — | — | — |
| View AuditLog | R (all) | R (own engagements) | R (assigned engagements) | — | — |
| View AIPrivacyLog | R (all) | R (own engagements) | R (assigned engagements) | — | — |
3. Provisioning
- The Managing Partner creates new user accounts in the Firm Settings page.
- New accounts default to
ARTICLErole. - Role elevation to
MANAGER/PARTNERrequires explicit action by the Managing Partner; the change is recorded inAuditLog. - The Managing Partner role is non-elevatable from inside the application; if it must change, the change is made by the existing Managing Partner via the Firm Settings page. There is no automatic succession.
4. Authentication requirements
| Role | Password | Two-factor | Session lifetime |
|---|---|---|---|
| MANAGING_PARTNER | 12+ chars | Mandatory | 12h inactivity / 7d absolute |
| PARTNER | 12+ chars | Strongly recommended | 12h / 7d |
| MANAGER | 12+ chars | Strongly recommended | 12h / 7d |
| ARTICLE / SENIOR_ARTICLE | 12+ chars | Optional | 12h / 7d |
| CLIENT | 12+ chars | Optional (link-based MFA on the roadmap) | 1h / 24h |
Passwords are stored as bcrypt hashes at cost factor 12 (Information Security Policy §2). The argon2id migration is on the roadmap.
5. Row-Level Security (RLS) enforcement
Postgres row-level security policies enforce engagement-scoping on every per-engagement table (every table whose primary key is engagementId-scoped). The application sets the engagement context per request via SELECT set_config('app.engagement_id', '...', true).
Cross-engagement reads must use the withSystemPrivilege wrapper, which:
- Sets
app.engagement_id = '*'for the transaction. - Is allowed only on firm-wide tables (TokenMap, IdentityHashIndex, etc.) where engagement scoping is structurally not applicable.
- Every such call carries a documented reason string visible to the rls-guard linter rule.
6. Off-boarding procedure
When a staff member leaves the Firm:
- The Managing Partner runs the off-boarding workflow on the user within twenty-four hours of leaving.
- The user is marked deactivated (
User.deletedAt = now()); login is blocked. - All active sessions are terminated via
prisma.session.deleteMany({ where: { userId } }). - Engagements assigned to the user are reassigned to the team's current article + manager via the engagement-management UI.
- SSH access to the production VM (if any) is revoked.
- The user's mobile authenticator token (if 2FA was enabled) is invalidated.
- The off-boarding action is recorded in
AuditLogand a one-line summary is added to the Firm's HR file.
7. Periodic access review
The Managing Partner reviews the full user list at the end of every quarter:
- Confirm every active user has a current business need.
- Confirm every active role is appropriate (no permission creep).
- Confirm 2FA is enabled where mandatory.
- Confirm no orphan sessions exist for deactivated users.
Review findings are recorded in docs/incidents/access-review-{YYYY-QQ}.md and any anomaly triggers a remediation task.
8. Client-portal access
A Client-portal user is created only after the engagement letter is in place and the client has nominated authorised individuals. The Managing Partner records the nomination + the e-mail address(es) in the engagement record.
A Client-portal user can:
- See the engagement's deliverables and uploaded documents (read).
- Upload further documents into the engagement's upload tray (write).
- Send query responses through the in-app message thread.
A Client-portal user cannot:
- See any other engagement.
- See any Firm internal review notes.
- See any AI-related view.
- See any audit-log row beyond their own actions.
9. Exceptions
Any exception to this policy is recorded in docs/legal/policy-exceptions.md with the Managing Partner's written approval and an expiry date.