Security at Movik

Governance and risk management

Our policy set covers acceptable use, access control, change management, cryptography, data classification and retention, secure development, logging and monitoring, incident response, business continuity, vendor management, and personnel security.

We maintain a risk register. Each entry records the asset and data involved, the threat, the controls in place, the residual risk, an owner, and a review date. Risks are reassessed on a recurring cadence and on any triggering event: a new integration, a new class of data, a vendor change, a security incident, or a finding from testing. Accepted risks are recorded with the rationale and the person accepting them, so nothing is left implicit.

Identity and access management

Authentication runs on Amazon Cognito. Customer and administrative identities live in separate user pools, so an administrative session cannot be produced from a customer credential.

• Sign-in uses Cognito’s Secure Remote Password exchange. The password is never transmitted — not to Movik’s servers and not to Cognito — and Movik never stores password material of any kind.
• Every authenticated request is checked against the signed token, not against a client claim. Tokens are verified against Cognito’s published JSON Web Key Set with the issuer, audience and expiry all enforced server-side.
• Session tokens are held in HTTP-only, Secure, SameSite cookies. Application JavaScript cannot read them, which removes the usual path from a script injection to a stolen session.
• Authorization is enforced at the API boundary. Server routes are wrapped in a single authorization layer that resolves the session, the role and the tenant before any handler code runs, so an endpoint cannot ship without an access decision.
• Administrative access follows least privilege and is granted by role, not by person. Any support session taken on a customer’s behalf is explicit, scoped and attributed to the operator who initiated it.
• Multi-factor authentication is required for administrative and cloud-console access.

Encryption and data protection

• All traffic to Movik is served over TLS 1.2 or higher. Plaintext HTTP is redirected, and HTTP Strict Transport Security is set.
• Data at rest is encrypted with AES-256 — the primary database, object storage for uploaded documents, and backups alike — using managed keys under AWS Key Management Service.
• Uploaded documents are stored in private object storage with no public read path. Access is by short-lived pre-signed URL issued only after an authorization check.
• Credentials, API keys and signing material are held as managed environment secrets in the deployment platform. They are never committed to source control and never inlined into client bundles.
• The browser is never given database access. A build-time check fails the build if any client component imports a database client, so privileged data access cannot reach the front end even by accident.
• Data is classified, and retention is set per class. Sensitive fields are minimized at collection: we ask for what a funding decision requires and no more.

Infrastructure and network security

Movik runs entirely on Amazon Web Services, in AWS-managed data centers covered by SOC 1, SOC 2, SOC 3, ISO 27001 and PCI DSS attestations. We inherit the physical and environmental controls of that platform and layer our own on top.

• Public traffic terminates at a CloudFront edge, which absorbs volumetric and protocol denial-of-service traffic before it reaches application capacity. AWS Shield is always on at the network and transport layers.
• A web application firewall sits in front of the application with managed rule sets for common exploits — SQL injection, cross-site scripting, known-bad inputs and reputation lists — plus rate-based rules that throttle abusive sources automatically.
• The database is not reachable from the public internet. Application servers reach it over private network paths, and administrative database access is restricted and logged.
• Row-level authorization is enforced in the data layer so a query cannot return another tenant’s rows, independent of the application code that issued it.
• Cloud IAM follows least privilege with scoped, role-assumed credentials rather than long-lived shared keys.

Application and bot defense

• Sensitive and unauthenticated endpoints require a Google reCAPTCHA assessment. We verify the token server-side and check both the risk score and the declared action, so a token minted for one form cannot be replayed against another.
• Request and response bodies are validated against explicit schemas at the API boundary. Unrecognized and malformed input is rejected rather than coerced.
• Dependencies are pinned by lockfile, updated on a schedule, and screened for known vulnerabilities. Findings are triaged by severity with remediation targets.
• Changes are peer-reviewed and merged through version control. Type checking, linting, automated tests and the security checks above run on every build, and a failure blocks the deploy.
• Production changes are traceable to a commit, an author and a review. Deployments are versioned and can be rolled back.

Monitoring, logging and incident response

Application and infrastructure events are logged centrally in AWS with retention, and security-relevant events — authentication failures, privilege use, administrative actions, configuration changes — are alerted on. Logs are scrubbed of secrets and sensitive values before they are written.

We maintain a written incident response plan with defined severities, an on-call path, containment and eradication steps, evidence preservation, and a post-incident review that produces corrective actions rather than a narrative. Where an incident affects customer data or a partner’s data, we notify affected customers and partners without undue delay and within the timelines our agreements and applicable law require.

Report a suspected vulnerability or incident to security@movik.us. We acknowledge reports and will work with the reporter through remediation. We do not pursue good-faith researchers who follow responsible disclosure.

Vendors and data sharing

Movik uses a small, deliberate set of specialist providers: Plaid for bank account connectivity, Veriff for identity verification, Middesk for business verification, DocuSign for executed agreements, and credit bureaus for commercial credit data. Each is assessed before onboarding for its security posture, its attestations, the data it needs and the terms it will sign, and each is reassessed periodically.

Bank connections are tokenized. Movik never receives, sees or stores end-user banking credentials; the connection is established by the provider and Movik holds only an access token scoped to what the customer authorized. Customers can revoke a connection at any time.

We share data with a vendor only where it is necessary to deliver the service the customer asked for, under contract, and limited to the fields that service requires. We do not sell customer data. See our Privacy Policy for how information is handled.

Resilience and continuity

The database is backed up automatically, encrypted, and supports point-in-time recovery. Restores are tested rather than assumed. Application infrastructure is managed and reproducible, so a rebuild is a deployment rather than a recovery project, and we maintain documented recovery objectives and a continuity plan covering loss of a region, a vendor or key personnel.

People

Access is provisioned on a need-to-know basis at hire, reviewed as roles change, and revoked on departure as part of a checklist rather than from memory. Personnel are subject to confidentiality obligations, receive security and phishing awareness training, and are required to use managed devices with disk encryption, screen lock and MFA for any access to production systems or customer data.

Policy documents

The governing policy and the plans partners most often request during diligence are published in full, and each can be downloaded as a PDF from its page.

• Information Security Policy — the governing document: governance, risk management, acceptable use, cryptography, secure development, logging, vendor and personnel security.
• Access Controls Policy — least privilege, the role model, authentication standards, privileged access, service credentials, access reviews and offboarding.
• Data Retention and Disposal Policy — the retention schedule, its regulatory basis, disposal methods, backup expiry and deletion requests.
• Incident Response Plan — severity classification, reporting, containment, evidence preservation, notification obligations and post-incident review.
• Business Continuity and Disaster Recovery Plan — recovery objectives, backup and restore, disruption scenarios, manual continuity of funding and testing.

Continuous improvement

The program is not static. Controls are reviewed against our current architecture, findings from testing and monitoring are tracked to closure, and our roadmap moves toward third-party attestation of the controls described here. We are glad to walk a partner’s security team through the underlying policies, our risk register and our architecture in detail under NDA.

Questions about this page or about Movik’s security program: security@movik.us.