Access Control Policy

1. Purpose

This policy sets out the requirements for authentication, authorisation, and the lifecycle management of user accounts and access rights across CompleteFlow systems, including access by CompleteFlow personnel to customer Azure subscriptions and access by end users to the CompleteFlow platform.

It implements CF-POL-001 section 5 and supports the controls described in CF-DOC-001 section 5.

2. Scope

This policy applies to:

• All CompleteFlow-issued accounts used by personnel and sub-processor personnel
• All service and automation accounts operating on behalf of CompleteFlow
• All access to customer Azure subscriptions by CompleteFlow personnel
• All configuration defaults for end-user access to the CompleteFlow platform

The policy does not govern end-user authentication within a customer's own Microsoft Entra ID tenant, which is the customer's responsibility. CompleteFlow supports customer-defined Entra conditional access and MFA policies and does not bypass or weaken them.

3. Principles

• Least privilege: users and services are granted only the minimum access required to perform their role.
• Separation of duties: sensitive operations require distinct actors where feasible (for example, change author and deployer, requester and approver).
• Minimised standing privilege: standing administrative access is restricted to the minimum number of named individuals required to operate the platform. Administrative access is always named, MFA-enforced, device-compliance-checked, and logged to the customer's own audit workspace. Just-in-time elevation via Azure PIM is implemented as the operating model scales (see section 7).
• Named accounts only: shared accounts are prohibited. Every privileged action is traceable to an individual.
• MFA by default: multi-factor authentication is required for all accounts with access to customer data or production systems.
• Auditable: every access grant, role change, authentication event, and sensitive action is logged and retained.

4. Authentication

4.1 Identity provider

CompleteFlow personnel authenticate to all CompleteFlow-managed systems via the CompleteFlow Microsoft Entra ID tenant. CompleteFlow does not operate separate local account directories for production systems.

Access to a customer's Azure subscription is granted via Entra B2B guest identity, federated from the CompleteFlow tenant, with conditional access and PIM applying at the customer tenant boundary.

4.2 Password standards

Password standards follow NCSC guidance and are enforced via Entra ID password protection and conditional access:

• Minimum length: 14 characters
• Complexity: mixed character types are not required (per NCSC passphrase guidance); common and breached passwords are blocked by the Entra password protection dictionary
• Rotation: on suspected compromise only (per NCSC guidance against mandatory periodic rotation for long, strong passwords protected by MFA)
• Reuse: the previous 24 passwords cannot be reused
• MFA: required for all accounts (see section 4.3)
• Password managers: personnel are required to use an approved password manager for any service that is not federated via SSO

4.3 Multi-factor authentication

MFA is enforced via Entra ID conditional access for all CompleteFlow personnel accounts, using the following methods in order of preference:

1. Hardware FIDO2 security key (preferred for privileged and administrative access)
2. Microsoft Authenticator app (push or TOTP)
3. Certificate-based authentication (for service accounts where applicable)

SMS and voice-call MFA methods are disabled.

4.4 Single sign-on and SAML

SSO via OpenID Connect is the platform's default authentication mechanism for end users in customer deployments. SAML 2.0 is supported on request. Where a third-party application does not support SSO, CompleteFlow evaluates the application against its standard supplier risk criteria (CF-POL-007); exceptions are recorded and reviewed annually.

4.5 Credentials and secrets

No long-lived credentials are stored in source code, configuration files, environment variables outside a secret store, or ticketing systems. All credentials, API keys, signing keys, and connection strings are stored in Azure Key Vault within the customer's Azure subscription or in CompleteFlow-managed Key Vaults for internal systems.

Automatic secret scanning runs on every commit; detection triggers immediate rotation and an incident-response review.

5. Authorisation and role-based access control

5.1 Three layers of RBAC

• Azure RBAC: governs CompleteFlow personnel access to customer Azure resources. Administrative roles are assigned to named individuals only (see section 7); the model uses minimised standing privilege today and transitions to PIM-based just-in-time elevation as the operations team scales.
• Application RBAC: governs end-user permissions within the CompleteFlow platform. Authorisation decisions are enforced by an in-process policy engine evaluating declarative policies, with authorisation decisions logged as part of the audit trail.
• Per-user credential broker: when the platform calls third-party APIs on behalf of a user, the call is authenticated as that user via per-user credentials stored in Azure Key Vault. No shared service accounts are used for downstream integrations.

5.2 Role definition

Roles are defined with the minimum permissions required to perform the role's function. Role definitions are reviewed at least annually by the Information Security Officer. New roles or material changes to existing roles require ISO approval.

5.3 Role assignment

Role assignment follows a documented request-approve-provision-review cycle. Assignments are reviewed quarterly for continued necessity; dormant or stale assignments are revoked.

6. Privileged access management

6.1 Current model

Administrative access to each customer's Azure subscription is held by a defined set of named individuals (see section 7) with the following controls:

• Named accounts only, federated to the customer's Entra ID tenant via B2B guest identity
• MFA enforced (hardware FIDO2 preferred; authenticator app otherwise)
• Conditional access restricts sign-in to CompleteFlow-managed devices meeting the CF-POL-004 compliance standard
• All administrative actions are logged to the customer's own Azure Monitor Log Analytics workspace and are not editable by CompleteFlow
• Change control on the named individual: adding, changing, or removing individuals with administrative access requires written notice to the customer
• The customer may configure Azure PIM on their own subscription to apply just-in-time elevation, time-boxing, or per-activity approval to any role at any point in the engagement

6.2 Transition to PIM-based just-in-time elevation

As the operations team scales, privileged access transitions to Azure Privileged Identity Management with the following controls:

• Access is requested for a named task with a documented reason
• Approval is granted by an authorised approver; elevation is time-boxed (typically 4 hours, maximum 8 hours)
• MFA is required at the point of elevation
• Conditional access restricts elevation to known, compliant devices and approved network locations
• All elevation events and actions taken during elevated sessions are logged to Azure Monitor Log Analytics in the customer's subscription

The transition will be communicated to customers in advance and documented in each customer's deployment specification.

6.3 Emergency (break-glass) accounts

A small number of break-glass emergency accounts are maintained for scenarios where PIM or identity services are unavailable. These accounts:

• Are cloud-only and not federated to on-premises or external systems
• Are excluded from automated conditional access policies that could lock out legitimate emergency use
• Are protected by long, unique, randomly-generated credentials held offline in a physically secure location
• Trigger high-priority alerts on any sign-in activity
• Have credentials rotated immediately after any use and at least annually

6.4 Separation of duties

Separation of duties is enforced structurally rather than relying solely on separate named roles:

• Code review: every change to production code requires a peer review on the pull request; the author may not merge their own change unassisted
• Automated deployment: production deployments are executed by infrastructure-as-code pipelines under a machine identity, so the act of approving a change (human reviewer) is separated from the act of executing it (pipeline), even when one individual is involved in both
• Customer audit: audit logs sit in the customer's own Azure Monitor Log Analytics workspace (not in CompleteFlow-editable storage), and the customer may review all CompleteFlow access independently of CompleteFlow's internal processes

Distinct named roles for change author, reviewer, release manager, and production operator are introduced as the operations team scales. The Information Security Officer reviews the SoD position at each annual policy review.

7. Access to customer environments and customer data

CompleteFlow customer deployments are actively co-developed alongside the customer, and the CompleteFlow access model reflects that reality while maintaining strong accountability and auditability.

7.1 Current model

In the current stage of the business, a single named individual (the Director and Information Security Officer) holds administrative access to each customer's Azure subscription for day-to-day configuration, deployment, testing, and support. That access is:

• Federated to the customer's Entra ID tenant via B2B guest identity, not a CompleteFlow-local account
• MFA-enforced (hardware FIDO2 preferred; authenticator app otherwise)
• Restricted by conditional access to CompleteFlow-managed devices meeting the CF-POL-004 configuration standard
• Fully logged to the customer's own Azure Monitor Log Analytics workspace (administrative actions, resource access, and data-plane access at the application level)

Adding or changing named individuals with access to a customer's subscription requires written notice to the customer and is recorded in the engagement file. Per-activity customer approval is not required for routine co-development, but the customer retains the ability to review all access in their own logs and to revoke access at any time.

7.2 Additional safeguards

• Routine deployment is handled by infrastructure-as-code pipelines and managed identities where possible, minimising direct human production access
• Where a customer wishes to apply additional controls (for example, configuring Azure PIM on their subscription to require customer-side approval for specific roles), CompleteFlow will support those controls
• The CompleteFlow application provides an in-UI audit log searchable by customer administrators, covering chat events, workflow runs, and document imports by default
• Azure Monitor logs may be exported to the customer's own SIEM via standard Azure diagnostic settings

7.3 Evolution of the model

As the operations team scales, the model transitions to Azure PIM-based just-in-time elevation, with no standing administrative roles and time-boxed activations (typically four hours, maximum eight). The transition is communicated to customers and documented in each customer's deployment specification. The Information Security Officer reviews the current model at each annual review and on any material change to the team or the engagement.

7.4 Customer oversight

The customer's Azure Monitor Log Analytics workspace holds the authoritative record of personnel access, available to the customer at any time. The customer may review activity, audit access, and revoke any CompleteFlow access at any time. Specific per-engagement arrangements (named individuals, scope, and any customer-specific approval gates) are documented in the customer's deployment specification and DPA.

8. Service and automation accounts

Where machine-to-machine authentication is required:

• Azure Managed Identities are preferred for service-to-service authentication; they remove the need to manage credentials
• Where managed identities are not available, service principals are used, with credentials stored in Key Vault and rotated automatically
• Service accounts have documented owners, defined purposes, and scoped permissions
• Service account credentials are never shared with human users

9. End-user access within the CompleteFlow platform

End-user access to a customer's CompleteFlow deployment is authenticated via the customer's Microsoft Entra ID tenant. CompleteFlow does not store end-user passwords or MFA factors.

Application-level roles within the platform are configurable by the customer's own administrator. Roles follow least-privilege design, with role changes subject to the customer's own change-management process. Default role templates are provided in product documentation.

10. Joiner, mover, and leaver (JML) process

10.1 Joiner

For each new CompleteFlow joiner:

• Pre-engagement screening is completed (CF-POL-001 section 7.5) before any access is granted
• A CompleteFlow-managed device is issued, configured under the device management standard, and handed over in person where practicable
• An Entra account is created with the minimum required roles; role additions require documented approval
• Induction training is completed (CF-POL-001 section 7.1), including a knowledge check, before access to customer data is granted

10.2 Mover

Where an individual changes role or responsibilities:

• Previous role permissions are reviewed and revoked where no longer required
• New permissions are provisioned under the request-approve-provision cycle
• Any customer-specific access is reviewed for continued necessity

10.3 Leaver

On departure of a CompleteFlow individual:

• All system access is revoked on the final day of engagement at the latest (immediately on termination for cause)
• The CompleteFlow device is returned and securely wiped
• Customer-specific access to customer Azure subscriptions is removed
• Where the individual had knowledge of shared secrets or break-glass credentials, those secrets are rotated immediately
• Departure is logged and reviewed by the Information Security Officer

11. Access reviews

• Quarterly: review of PIM-eligible role holders for continued necessity
• Quarterly: review of service and automation accounts for owner and scope
• Annually: review of role definitions and minimum-privilege appropriateness
• On material change: review following re-organisation, sub-processor change, or significant architecture change

12. Logging and monitoring

All authentication events, PIM elevations, role changes, and sensitive administrative actions are logged to Azure Monitor Log Analytics and retained per CF-DOC-001 section 7.1.

Microsoft Defender for Cloud surfaces built-in alerts on suspicious authentication patterns. Custom KQL alert rules cover CompleteFlow-specific patterns, including elevation outside business hours, sign-in from unusual locations, and unusual resource targets.

13. Exceptions

Exceptions to this policy require a documented request, a compensating control proposal, and approval by the Information Security Officer. Exceptions are time-bound, recorded in the risk register (CF-REG-001), and reviewed at least quarterly.

14. Document control