Information Security Policy — Veloxis

Effective date: [to be set on first publication] Last revised: 2026-05-24 Policy owner: CA Krishna Gujarathi Scope: All systems, data, and personnel involved in operating or using the Veloxis Platform inside VKG & Associates.

This policy sets out the minimum controls for protecting Firm and client data inside Veloxis. It is the internal, controls-level companion to the public-facing Privacy Policy and Terms of Service.

The policy is structured against the ISO/IEC 27001:2022 Annex A control families for future certification readiness, but is sized to the Firm's current single-server, single-firm scale.

1. Information classification

All data inside Veloxis is treated as at-least C3 unless explicitly marked otherwise.

2. Identity and access

• Authentication — every login uses an e-mail + password issued under the Firm's password policy (12+ characters, mixed case, digit, special). Passwords are hashed using bcrypt at cost factor 12 in the current production deployment; the Firm's roadmap migrates to argon2id once the credential-rotation script is in place. The hashing algorithm in use is auditable from the application source code at the commit deployed.
• Multi-factor authentication — strongly recommended for all partners and managers; mandatory for the Managing Partner. The Platform supports TOTP-based 2FA.
• Session lifetime — JWT sessions expire after 12 hours of inactivity; absolute maximum 7 days.
• RBAC — five roles enforced on every API call:

• Least privilege — newly-added users are created as ARTICLE by default and elevated on need.
• Off-boarding — when a staff member leaves the Firm, the Managing Partner runs the off-boarding workflow within 24 hours: deactivate the user, terminate all sessions, transfer ownership of any assigned engagements.

3. Data protection at rest

• Database — PostgreSQL 14+, hosted on the production VM, disk encryption via LUKS on the host disk.
• TokenMap.plaintextEncrypted — AES-256-GCM, key derived from the firm key + the engagement identifier via HKDF. IV stored as the first 12 bytes of the ciphertext.
• TokenMap.plaintextHash — HMAC-SHA-256; never reversible; used only for same-value-same-token deduplication during ingestion.
• R2 object storage — server-side encryption via Cloudflare R2 default encryption; bucket policy denies public listing.
• Backups — taken nightly via pg_dump --format=custom and pushed to a private R2 bucket; backup file is encrypted with a separate BACKUP_AES_KEY before upload.
• Local logs — rotated via logrotate; compressed daily; old log files purged at 30 days for application logs and 90 days for access logs.

4. Data protection in transit

• Public endpoints — HTTPS only, TLS 1.2 or higher, Let's Encrypt certificates. HTTP requests on port 80 are redirected.
• Internal endpoints — the Tokenisation Sidecar listens on 127.0.0.1:8765 only, never on a public interface. Auth via shared header X-Sidecar-Secret.
• Database — PostgreSQL listens on 127.0.0.1:5432; never exposed publicly.
• Outbound to AI providers — TLS 1.3 client connections to api.anthropic.com and generativelanguage.googleapis.com. The Node https client verifies certificates.
• Cloudflare proxy — DNS-only mode (grey cloud). The proxy is not enabled because the Firm wants TLS termination on the Firm's own server, not on Cloudflare's edge.

5. Cryptographic-key management

Keys live in .env and .env.prod only on the production VM. Both files are mode-600 and owned by the application user. The Firm acknowledges that file-based environment variables are not a secrets-manager solution; migration to a dedicated secrets store (e.g., Vault, AWS Secrets Manager, or an Indian-hosted equivalent) is on the roadmap and will be implemented before the Firm offers Veloxis to third-party firms. In the interim, key access is restricted by SSH key authentication, mode-600 file permissions, and SSH-key rotation on staff off-boarding.

6. Application security

• Input validation — every API route validates input via Zod schemas at the route boundary. Untyped JSON bodies are rejected.
• Output sanitisation — server responses do not include stack traces, internal IDs (beyond the routing CUID), or environment information.
• CSRF / XSS — Next.js framework defaults (strict cookie flags, React's automatic HTML escaping); no dangerouslySetInnerHTML accepted in code review.
• SQL injection — Prisma ORM exclusively; raw SQL only for the audit-engine and only with parameterised queries.
• Rate limiting — /api/ai-check, /api/ai-advisor/*, /api/engagements/[id]/ai-tokenisation-preview are rate-limited per user per minute and per user per day.
• Privacy enforcement — every AI call funnels through runPrivacySafeMessage(). The PrivacyEnforcementError guard refuses to send to the provider if the Tokenisation Sidecar is unavailable.

7. Supply chain

• Code — production deployments build from the master branch of github.com:kgujarathi/veloxis.git. The build is reproducible from the commit hash printed at deploy.
• Dependencies — npm ci enforces package-lock.json. Dependabot / GitHub Advanced Security alerts are reviewed weekly.
• Third-party licences — docs/legal/third-party-licenses.csv is regenerated on every major upgrade and reviewed for incompatible licence changes.
• Sub-processors — see docs/legal/ai-usage-disclosure.md for the current AI provider list. The wider sub-processor register lives at docs/legal/vendor-register.md (to be authored).

8. Logging and monitoring

All ICT system logs are mandatorily retained for a rolling 180 days under §IV of the CERT-In Cyber Security Directions, 2022, and remain physically located within Indian jurisdiction on the production VM. Logs are reviewed weekly for anomalies. The first response to a suspected incident is always to capture the relevant log window into the incident folder (docs/incidents/...).

8.1 Time synchronisation

In compliance with §III of the CERT-In Directions, 2022, all servers, virtual machines, network devices, and other ICT clocks operated by the Firm shall be synchronised to the National Informatics Centre (NIC) NTP server (samay1.nic.in, samay2.nic.in) or the National Physical Laboratory (NPL) NTP server. The synchronisation is checked at boot and at thirty-minute intervals via chronyd. Drift greater than 250ms triggers an alert and a follow-up correction.

The Firm does not synchronise to international NTP pools (pool.ntp.org) on production infrastructure, because CERT-In requires NIC/NPL.

9. Change management

• All code changes flow through a Git branch + pull request + review on the master branch.
• Schema changes require Prisma migration files; no prisma db push in production except via the deploy script with explicit sign-off.
• Deploys use ./deploy.sh which builds, runs the smoke health-check on the local + public URL, restarts the production process, and only then resumes the dev process.

10. Privacy controls

The Tokenisation Pipeline v2 + Pseudonymisation pack from May 2026 (see docs/privacy-and-tokenization.md) is the standing privacy control set. Material updates to that control set are reviewed against this policy and the AI Usage Disclosure before release.

11. Physical security

The production server is hosted in a Linode datacentre under Linode's physical-security regime (SOC 2 Type II). The Firm does not have physical access to the server. Console access is via SSH using key-based authentication only; password SSH is disabled.

12. Personnel security

• Confidentiality undertakings — every employee (staff, articled clerk, contractor) signs a confidentiality undertaking on joining that incorporates the ICAI Code of Ethics Volume II, §3.
• Training — annual training on the Privacy Policy, this policy, the Incident Response Plan, and basic phishing awareness.
• Access review — the Managing Partner reviews the user list quarterly and confirms every active user has a current business need.

13. Vendor and sub-processor management

A vendor is engaged only if:

• They publish security and privacy terms acceptable to the Firm.
• They commit to no training on customer data (for AI providers).
• They publish retention windows compatible with the Firm's policies.

The Firm reviews the published terms of each vendor annually. Any material adverse change triggers an out-of-cycle review and, where necessary, vendor migration.

14. Policy exceptions

Exceptions to this policy require written approval from the Managing Partner. Each exception is dated, time-bound, and recorded under docs/legal/policy-exceptions.md.

15. Review

This policy is reviewed annually. The next scheduled review is 2027-05-24.