Access Controls Policy

1Purpose

This policy establishes how Movik grants, enforces, reviews and removes access to production systems and to sensitive data. Movik advances funds against freight invoices and holds the financial records that support those advances. Unauthorized access to those systems would allow financial loss or the disclosure of customer financial information, so access is treated as a primary control rather than an administrative convenience.

2Scope

This policy applies to all Movik personnel, contractors and service providers, and to every system that stores or processes Movik or customer data. In scope: the Movik application and its API, the production database, object storage holding customer documents, the AWS account and console, the Cognito user pools, source control and the deployment pipeline, and the administrative interfaces of every third-party provider listed in clause 10.

Movik operates no data centers or physical server infrastructure of its own. Physical access control for production infrastructure is inherited from Amazon Web Services and is addressed in clause 12.

3Data classification

Access decisions are made against the classification of the data involved.

4Principles

• Deny by default. Access is granted explicitly. An identity with no grant has no access, and application endpoints require an authorization decision before any handler logic executes.
• Least privilege. Each identity receives the minimum access its function requires, for the shortest period it is required.
• Need to know. Restricted data is reachable only by personnel whose role requires it, not by all administrators as a class.
• Verify every request. Trust is not inferred from network position. Every request to a protected resource is authenticated and authorized against a cryptographically verified identity, on every call.
• Attribution. Every privileged action resolves to an individual. Shared accounts are prohibited (clause 8).

5Identity and authentication

6Authorization model

Movik enforces role-based access control. Roles are attached to identities; permissions are attached to roles; permissions are never attached to individuals.

• The application defines two principal identity classes — customer and administrator — each backed by its own Cognito user pool, plus tenant scope, which confines a customer identity to the records of the organization it belongs to.
• Within the administrator class, access is further divided into named roles, each carried as a group membership on the administrator identity and granting a fixed set of permissions. Read access to backoffice records is common to every administrator role; the roles differ in what each may modify. Super-Admin may write anywhere, and additionally holds the three capabilities no other role has: acting as a customer identity, deleting accounts, and administering roles. Operational may write across the operational cycle — debtor and credit-bureau review, approval decisions, loads, documents, notices of assignment and disbursements. Sales-Manager may export user records and nothing else. Sales-Rep holds no write capability of any kind. An administrator identity holding no role receives no permissions at all, read included.
• Authorization is enforced at a single API boundary. Server routes are wrapped in one authorization layer that resolves the session, the identity class, the tenant and the permission required by the route before handler code runs. The route-to-permission mapping is declared in one place and is the sole authority; a route absent from it is denied rather than allowed. An automated test enumerates every administrative route in the codebase and fails the build if any route has no declared permission, so an endpoint cannot be shipped without an access decision having been made.
• Row-level authorization is additionally enforced in the data layer, so a query cannot return another tenant’s records irrespective of the application code that issued it. Authorization therefore fails closed if application logic is wrong.
• The browser is never granted database access. A build-time check fails the build if any client-side component imports a database client, preventing privileged data access from reaching the front end.

7Provisioning and modification

• Access is requested by the person’s manager or by the individual, and approved by the Security Program Owner or a delegate. The approval records the role granted, the systems in scope, the business justification and the date.
• Access is provisioned to the approved role only. Requests for access beyond a defined role are handled as exceptions under clause 15.
• On a change of role, access is re-derived from the new role rather than added to. Access no longer required by the new role is removed as part of the same change.
• Provisioning and de-provisioning are performed against a written checklist enumerating every in-scope system, so removal does not depend on recollection.

8Privileged and administrative access

• Administrative access is granted by role and to named individuals. Shared, generic or team accounts are prohibited in all production systems.
• AWS access uses scoped, role-assumed credentials. Long-lived shared access keys are not used for interactive access, and the account root credential is protected by multi-factor authentication and not used for routine operations.
• Direct administrative access to the production database is restricted to personnel whose role requires it, and is logged.
• Where support staff must act on a customer’s behalf, the application provides an explicit, scoped session that is attributed in logs to the operator who initiated it. Operators do not use customer credentials, and customer credentials cannot be recovered by Movik personnel.
• Production data is not copied into development or test environments. Where realistic data is required for testing, it is synthetic.

9Non-human and service credentials

• Service-to-service authentication uses OAuth tokens or role-assumed credentials wherever the counterparty supports it — including the OAuth 2.0 JWT bearer grant signed with a private key for document execution, Cognito-issued OIDC tokens between Movik components, and AWS role assumption for cloud resources. Where a provider offers only a static API key, that key is transmitted exclusively over TLS and scoped to the narrowest available permission.
• All credentials, API keys and signing material are held as managed environment secrets in the deployment platform. Credentials are not committed to source control and are not included in client-side bundles.
• Service credentials are rotated on a defined schedule, and immediately on suspected exposure or on the departure of anyone who held them.
• Automated jobs authenticate with their own dedicated credential rather than reusing a human identity.

10Third-party access

Movik uses specialist providers for bank account connectivity, identity verification, business verification, document execution, commercial credit data and transactional messaging. Each is assessed before onboarding and reassessed periodically, and each is granted only the data its function requires.

• Provider administrative consoles are treated as production systems: named accounts, multi-factor authentication, and inclusion in the access review under clause 11 and the offboarding checklist under clause 13.
• Bank account connections are tokenized. Movik does not receive, view or store end-user banking credentials, and holds only an access token scoped to what the customer authorized. Customers may revoke a connection at any time.
• Providers have no standing access to Movik production systems. Support access, where required, is time-boxed, supervised and revoked on completion.

11Access reviews

The Security Program Owner performs a documented access review at least quarterly, and on any event affecting the access population — a departure, a role change, an incident, or the addition of a system or provider.

• The review enumerates every identity in each in-scope system: both Cognito pools — including the role held by each administrator identity — AWS IAM principals and roles, production database accounts, source control and deployment access, and every provider console.
• Every change to an administrator role is recorded in the audit trail with the identity changed, the role before and after, the approver and the stated justification, and terminates the affected person’s sessions so that the previous role stops applying immediately rather than at the next token renewal.
• Each identity is confirmed as still required at its current level, reduced, or removed. Removals are executed during the review rather than deferred.
• The completed review is retained as evidence, recording the date, the reviewer, the population examined and every change made. Retention of these records is set by the Data Retention and Disposal Policy.

12Physical access

Production infrastructure resides in Amazon Web Services facilities, whose physical and environmental controls are covered by AWS’s SOC 1, SOC 2, SOC 3, ISO 27001 and PCI DSS attestations. No Movik personnel have physical access to production infrastructure, and no Movik-controlled premises hold production systems.

Devices used to access production systems or Restricted data must have full-disk encryption, an enforced screen lock, and current operating system and browser versions. Production access from shared or public devices is prohibited.

13Transfers and terminations

• On termination, access to all in-scope systems is revoked on the final day of employment, and immediately on an involuntary termination. Revocation follows the checklist in clause 7 and covers the Cognito administrative pool, AWS, source control, the deployment pipeline, the database, and every provider console.
• Any shared service credential known to the departing person is rotated as part of the same process.
• Company devices are returned and their access to Movik systems removed.
• Completed revocation is recorded, and the next access review under clause 11 confirms no residual access remains.

14Logging and monitoring of access

Authentication events, authorization failures, administrative actions, support sessions taken on a customer’s behalf, and configuration changes are logged centrally in AWS with defined retention. Security-relevant events are alerted on. Logs are scrubbed of secrets and sensitive values before they are written, and access to the logs is itself restricted by role.

15Exceptions

Any deviation from this policy requires written approval from the Security Program Owner and is recorded in the risk register with a compensating control, an owner and an expiry date. Exceptions are reviewed at each access review and are not renewed by default.

16Enforcement and review

Personnel are made aware of this policy on hire and at each material revision. Non-compliance may result in withdrawal of access and disciplinary action up to termination. This policy is reviewed at least annually by the Security Program Owner, and on any material change to Movik’s architecture, data flows, provider set or regulatory obligations. Revisions are versioned, and the effective date in the document control block above reflects the current version.

Questions about this policy: support@movik.us.