Technical controls matter when they can be located, tested and explained. This page describes the safeguards visible in Cyntrova’s current application and release paths—and marks the operating details that still require deployment-specific confirmation.
CONTROL 01IdentitySigned session + server-side stateVERIFIED
CONTROL 02AuthorityRole and permission checksVERIFIED
CONTROL 03BoundaryFirm and client contextVERIFIED
CONTROL 04EvidenceActor-scoped audit recordsWORKFLOW-SCOPED
Security should be inspectable, not implied.IMPLEMENTATION · CONFIGURATION · OPERATION
01 / CONTROL REGISTER
Evidence has different owners.
A product safeguard can be verified in code. A hosting control depends on the deployed environment. A company practice must be continuously operated. We keep those categories separate.
Control areaCurrent practiceEvidence status
Authentication
Signed, time-bounded session with server-side verification and revocation state.
VERIFIED IN PRODUCT
Access control
Active membership, explicit permission and client assignment checks protect scoped routes.
VERIFIED IN PRODUCT
Hosting & encryption
HTTPS enforcement and security headers are visible in code; provider-level storage and backup settings require environment evidence.
CONFIRM DEPLOYMENT
Operational response
Request logging, health checks and a reporting channel exist; response procedures must remain operated and tested.
OPERATED PRACTICE
Assurance boundary: this is an engineering-practices statement, not a certification or independent-attestation claim.
02 / AUTHENTICATION & ACCOUNT SECURITY
Identity opens the door. Context decides the action.
A successful sign-in does not create unrestricted authority. Session verification is followed by workspace membership, client scope and permission checks.
01 / SESSION
Signed and time-bounded
Malformed, tampered or expired tokens are rejected. Production session cookies are configured as secure, HttpOnly and SameSite.
02 / MEMBERSHIP
Active workspace relationship
The user, firm and membership must remain active before protected context is created.
03 / PERMISSION
Capability for the action
View, review, approve, post, reverse, export and administration rights can be granted separately.
04 / RESOURCE
Firm and client boundary
Client-scoped work is checked against firm ownership and the member’s configured access.
ACCOUNT DEFENCE
Authentication and password-recovery endpoints use dedicated rate limits in addition to the API’s general request limit.
SESSION REVOCATION
Session state includes expiry and revocation. Signing out revokes the matching server-side record before the browser cookie is cleared.
DENIAL EVIDENCE
Firm, client and permission failures can produce audit events with the actor, requested resource and reason.
03 / TENANT & BUSINESS DATA ISOLATION
The boundary is part of every protected request.
Cyntrova does not rely on a screen hiding the wrong record. Protected API routes build and require a trusted tenant context before application services receive the request.
If a required relationship is missing or points outside the active tenant, the protected action is denied.
ALLOWEDService receives scoped identity and authority.DENIEDRequest stops before the protected operation.RECORDEDRelevant denial context can enter the audit trail.
04 / INFRASTRUCTURE & HOSTING
A secure release is more than a deploy.
Cyntrova’s configured production API release path targets managed Azure hosting and authenticates CI to Azure with short-lived identity federation rather than a long-lived deployment password.
01
Locked installation
Production CI installs the repository’s locked dependency graph before building.
02
Deterministic gates
Type, lint, tests, accounting constraints and builds run in the quality workflow.
03
OIDC deployment
The Azure deployment workflow uses GitHub identity federation and scoped repository secrets.
04
Post-release checks
Health, deployed version and database-schema readiness are checked after release.
ISOLATION IS EXPLICIT
One authorised path does not open every lane.
ENCRYPTION IN TRANSIT
Enforced at the application boundary.
Production public origins must use exact HTTPS URLs. The API enables strict transport headers in production and refuses wildcard or insecure browser origins.
VERIFIED IN CODE
ENCRYPTION AT REST
Confirm against the live providers.
Database, object-storage and backup encryption depend on the selected provider and deployment configuration. Cyntrova does not represent one universal at-rest setting here without current environment evidence.
DEPLOYMENT EVIDENCE REQUIRED
05 / SECRETS & CREDENTIAL HANDLING
Private values should stay out of public code.
The repository separates public browser configuration from server-side credentials. Production release inputs are referenced through CI or hosting-provider secret settings.
Server-side only
Database, storage, internal-service and AI-provider credentials are read from server environment configuration—not browser-prefixed variables.
Federated cloud login
The production API workflow uses Azure OIDC credentials so CI can authenticate without committing a deployment secret to the repository.
Fail-closed production checks
Required production secrets and exact secure origins are validated before the API starts.
06 / AUDITABILITY, FILES & DATA
Keep the source private. Keep the action traceable.
Financial evidence needs both access control and a record of consequential actions. Cyntrova’s application services use scoped document delivery and structured audit context.
FILE & DOCUMENT HANDLING
Authenticated storage and expiring access.
Document workflows can use authenticated object delivery and time-limited signed URLs for upload, download and evidence crops. The signing credentials stay server-side.
No permanent public URL required for the workflow
Short-lived access is generated for the requested operation
File type and size validation remain workflow responsibilities
AUDIT LOGGING & TRACEABILITY
Actor, context, action and resource.
Audit records support request, firm, optional client, actor, role, action, resource, reason and before/after hash context where supplied.
Access denials are explicitly represented
Relevant financial and settings actions write workflow events
Coverage is workflow-specific—not a claim that every click is logged
07 / BACKUPS, RECOVERY & MONITORING
Resilience must be demonstrated in operation.
Code can define readiness checks; it cannot prove that a provider backup completed last night or that a restore drill succeeded. Those are operating facts and should be evidenced for the live deployment.
CONFIRM DEPLOYMENT
Backups & restore
Confirm the active database-backup schedule, retention window, storage isolation and date/result of the latest restore test.
Ask for
Provider evidence
Verify
Restore drill
Record
RPO / RTO
OPERATED PRACTICE
Monitoring & release health
API request logs include request ID, method, path, status and duration. Production release automation checks health, deployed version and schema readiness.
Visible
Request context
Checked
Health + version
Confirm
Alert routing
MATURITY BOUNDARY
Incident readiness
Reporting is available today. Response ownership, escalation, evidence retention and recovery procedures must remain current and rehearsed.
Report
Email channel
Preserve
Safe evidence
Practice
Response drill
08 / SECURE DEVELOPMENT PRACTICES
Changes should earn their way to production.
Cyntrova’s repository quality gates favour deterministic verification: isolated database migrations, accounting constraints, types, lint, API and worker tests, production builds and browser checks.
01
Review the change
Keep scope small, protect stable auth, tenant and accounting boundaries, and inspect migrations before release.
02
Test in isolation
CI provisions an isolated database, applies migrations and runs accounting constraints plus product tests.
03
Build before deploy
Workspace packages and applications are built from locked dependencies; release-specific regression gates run before the API package is created.
04
Verify after deploy
The production workflow checks service health, expected revision and schema readiness instead of treating upload completion as success.
09 / VULNERABILITY & INCIDENT REPORTING
Tell us what you observed. Do not send the secret itself.
Report suspected unauthorised access, exposed links, credential compromise or a reproducible vulnerability. Include the affected surface, approximate time, impact and safe reproduction steps.
admin@cyntrova.com Do not email passwords, session tokens, private keys or unnecessary financial documents.
SECURITY SHOULD BE INSPECTABLE, NOT IMPLIED.
Ask for the evidence your workflow requires.
Architecture, configuration and operations all matter. Review Cyntrova against your access model, data sensitivity and recovery expectations before rollout.
