[Company] Access Control Policy

• Version: 1.0
• Owner: Founder/CTO
• Approved by: Chief Executive Officer (CEO)
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This policy defines how [Company] controls access to its systems, applications, and data. It sets out who may be granted access, how access is requested and approved, how it is reviewed, and how it is removed when it is no longer needed. The goal is to make sure that only authorized people and systems can reach [Company]'s information, and only to the extent their role requires.

[Company] handles personally identifiable information (PII) belonging to its customers and their end users. Controlling access properly reduces the risk of that data being viewed, changed, or disclosed without authorization, and supports [Company]'s commitments under its SOC 2 program and applicable US state privacy laws such as the California Consumer Privacy Act (CCPA).

2. Scope

This policy applies to all [Company] employees and contractors, and to any third party granted access to [Company] systems, and covers all systems that store, process, or transmit [Company] or customer data, including its cloud infrastructure (Amazon Web Services), productivity and collaboration suite (Google Workspace), source code repository (GitHub), and any other business application used to run the company.

3. Policy

Access to [Company] systems and data must be granted only on the basis of a demonstrated business need, following the principle of least privilege, and must be requested, approved, and recorded before it is provisioned. Access must be reviewed on a regular basis and removed promptly when it is no longer required, including when an employee or contractor leaves the company or changes role.

4. Access Control Model

[Company] uses role-based access control (RBAC) as its primary access model. Access to systems and data is assigned according to a person's job function (for example, engineering, customer support, or finance) rather than granted to individuals one request at a time. This approach is well suited to a small, fast-growing company because it lets new hires be provisioned quickly and consistently by assigning them the standard access bundle for their role, rather than relying on someone remembering the individual systems a new joiner needs.

All access, whether assigned through a role or granted individually, must also follow the principle of least privilege: a person or system is given the minimum access needed to do its job, and no more. As [Company] grows, roles and their associated access bundles must be kept up to date so that RBAC continues to reflect what people actually need.

5. Access to Networks and Network Services

[Company] operates entirely in the cloud and has no on-premises network to secure; "network access" in this policy means access to cloud infrastructure (AWS), business applications (Google Workspace), and source code systems (GitHub). Access to these services must only be possible after successful authentication, and multi-factor authentication (MFA) must be enabled and required for every system that supports it. Remote workers must not share accounts, devices, or credentials used to reach [Company] systems.

6. User Access Management

Access to [Company] systems is managed centrally wherever possible through Google Workspace, which acts as the primary identity source for company accounts, supplemented by direct account management in AWS and GitHub where Google Workspace is not used for sign-in.

6.1 User Registration and Deregistration

Every person who needs access to [Company] systems must have a unique, individually identifiable account; shared or generic accounts are not permitted except for documented service accounts. An account must be created only after a request has been approved as described in section 6.6, and must be deregistered (disabled or deleted) as described in section 6.5 when it is no longer needed.

6.2 User Access Provisioning

When a new employee or contractor joins, or an existing person changes role, access must be provisioned according to the standard role bundle that matches their job function, plus any additional access specifically approved. Provisioning must include:

• Creating or updating the person's Google Workspace account, which is used to sign in to supported applications.
• Adding the person to the appropriate groups or teams in AWS and GitHub that correspond to their role.
• Enabling multi-factor authentication before any access is used.
• Recording what was granted, to whom, by whom, and when.

6.3 Management of Privileged Access

Privileged access (such as AWS account administrator or IAM permissions, GitHub organization owner rights, or Google Workspace super administrator rights) must be limited to the smallest number of people who need it to do their job, and wherever the system supports it, administrators must use a separate account for administrative tasks rather than their everyday user account. Grants of privileged access must be individually recorded and are subject to more frequent review than standard access, as set out in section 6.4.

6.4 User Access Reviews

The Founder/CTO must review all privileged access at least every quarter, and all other user access at least every six months, to confirm that each person's access still matches their current role and is still needed. Access to systems that store or process customer PII must be included in every review. Reviews, and any access changes that result from them, must be recorded.

6.5 Removal and Adjustment of Access Rights

Access must be removed immediately, on the same day, when an employee or contractor departs involuntarily or when access is identified as posing an immediate risk. For all other departures, access must be removed within 5 business days of the person's last working day. Where a review or role change finds that a person's access is no longer needed or is broader than required, it must be adjusted within 5 business days of that finding. Accounts that have not been used for 30 consecutive days must be disabled pending confirmation that they are still needed.

6.6 Access Provisioning, Deprovisioning and Change Procedure

The step-by-step process for requesting, approving, modifying, and removing access is set out in Appendix A. All access changes, whether for new hires, role changes, or departures, must follow that procedure.

6.7 Segregation of Duties

[Company]'s small team means the same person (the Founder/CTO) often requests, approves, and provisions access for others. To compensate for this, every access grant must be recorded in a log that includes who requested it, who approved it, and who provisioned it, and this log must be reviewed by another authorized member of the team (such as the CEO) at least every quarter as part of the access review described in section 6.4. Where the team has grown enough that a request, an approval, and the provisioning of access can be handled by three different people, that separation must be used instead.

7. User Responsibility for Authentication Information

Every person with access to [Company] systems is responsible for keeping their passwords, security keys, and other authentication information confidential, and must not share their account or credentials with anyone else, including other employees. Any suspected compromise of a password or account must be reported to the Founder/CTO immediately.

7.1 Password Policy

• Passwords must be at least 12 characters long.
• [Company] does not require periodic password rotation unless there is reason to believe a password has been compromised.
• Multi-factor authentication must be enabled on every account and system that supports it, in addition to a password.
• Accounts must lock for 15 minutes, or until reset by an administrator, after 5 consecutive failed login attempts.
• Default or vendor-supplied passwords must be changed before a system is put into use.

8. System and Application Access

Access to individual systems and applications must follow the role-based bundles described in section 4, and must be restricted so that a person can only reach the specific systems, data, and functions their role requires.

8.1 Secure Log-on Procedures

Systems must not reveal which part of a login attempt (username or password) was incorrect, must not display more information than necessary before a user is authenticated, and must require multi-factor authentication where supported. Idle sessions on administrative interfaces for AWS, GitHub, and Google Workspace must lock or time out after 15 minutes of inactivity.

8.2 Password Management System

Where possible, password policies described in section 7.1 must be enforced through the built-in security settings of Google Workspace, AWS, and GitHub, rather than relying on individuals to apply them manually. Employees must use a password manager to generate and store credentials rather than reusing passwords across systems.

8.3 Use of Privileged Utility Programs

Tools or scripts capable of overriding normal system or application controls, such as AWS root account actions, GitHub organization-level administration, or infrastructure automation with elevated permissions, must be restricted to authorized administrators, must not be used for routine day-to-day work, and their use must be logged.

8.4 Access to Program Source Code

Access to [Company]'s source code repositories in GitHub is granted according to role and must be limited to the engineers who need it. Changes to production branches must go through a pull request with review by another engineer before merging, and force-pushes or history rewrites on protected branches are not permitted. Repository administrator rights are limited to the Founder/CTO or engineers specifically designated for that purpose.

9. Exceptions

Any exception to this policy must be requested from the Founder/CTO, documented in writing with the reason for the exception, and time-limited, with a defined date by which the exception will be reviewed or removed.

10. Violations & Enforcement

Failure to comply with this policy, including sharing credentials, bypassing access controls, or granting access without following the procedure in Appendix A, may result in disciplinary action up to and including termination of employment or contract, and may result in immediate suspension of system access while the matter is investigated.

11. Appendix A: Access Management Procedure

This appendix sets out the practical steps for requesting, approving, changing, and removing access to [Company] systems.

11.1 Access Request and Approval Process

• A request for new or changed access must identify the person, the system, the specific access needed, and the business reason.
• Requests must be approved by the Founder/CTO or, where the Founder/CTO is the person requesting access for themselves, by the CEO.
• Approved requests must be provisioned promptly and recorded in the access log described in section 6.7, including who requested, approved, and granted the access.
• Service accounts and API keys must have a named human owner responsible for them, must be limited to the minimum permissions needed, and must be included in access reviews.
• Accounts held by suppliers or support providers must have a defined end date at the time they are created, matching the expected length of the engagement, and must not be left open indefinitely.
• If the normal approver is unavailable, the CEO may grant emergency access. Emergency access must be time-limited to no more than 24 hours, must be logged, and must be reviewed by the Founder/CTO as soon as they are available afterward.

11.2 Access Modification and Removal Process

• When a person changes role, their access must be updated to match their new role bundle, and any access no longer needed must be removed within 5 business days of the change.
• When a person departs involuntarily, or access is found to pose an immediate risk, access must be removed the same day.
• For all other departures, access must be removed within 5 business days of the person's last working day.
• Supplier and support accounts must be disabled on or before their defined end date, unless a new end date is approved in advance.
• All removals and modifications must be recorded in the access log, including the date access was removed and who carried it out.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Access Control Policy

• Version: 1.0
• Owner: Head of Information Security
• Approved by: Chief Technology Officer
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This policy sets out the rules that govern who may access [Company]'s systems and data, and how that access is requested, approved, granted, reviewed and removed. It exists to protect the confidentiality, integrity and availability of the personally identifiable information and financial data that [Company] processes on behalf of its customers, and to make sure that only authorised individuals can reach the systems and information they need to do their jobs.

[Company] operates in the financial services sector and serves banks and other FCA-regulated firms. Weak or poorly managed access controls are one of the most common causes of data breaches and regulatory findings, and several of the frameworks [Company] follows, including ISO 27001, SOC 2 and DORA, require a documented and consistently applied approach to access control. This policy supports [Company]'s information security policy and gives it practical effect.

2. Scope

This policy applies to all employees, contractors and temporary staff of [Company], and to all systems, applications, networks and data that [Company] owns, operates or manages, including cloud infrastructure hosted on AWS, identity and collaboration services such as Okta and Microsoft 365, and any other business system used to store or process company or customer data. It also applies to accounts held by suppliers or support providers who are given access to [Company]'s environment.

3. Policy

[Company] grants access to its systems and data on the basis of business need and job role only, and access must be requested, approved and recorded before it is granted. Every account, whether held by an employee, a contractor, a supplier or a system, must have an identifiable owner and a defined purpose. Access rights are reviewed regularly, removed promptly when no longer needed, and access to particularly sensitive functions is subject to additional controls described in this policy.

4. Access Control Model

[Company] uses role-based access control (RBAC) as its primary model. Under RBAC, access rights are grouped into roles that reflect a job function (for example, "finance analyst" or "platform engineer"), and individuals are granted the role that matches their job rather than being given permissions one at a time. This approach is well suited to [Company]'s size and its rate of hiring, because it lets new starters be provisioned quickly and consistently through a small number of pre-defined role bundles, rather than relying on someone remembering every permission an individual needs.

All access, whatever the model used to grant it, is governed by the principle of least privilege: individuals and service accounts are given the minimum level of access needed to perform their function, and no more. Access to particularly sensitive systems, such as production infrastructure and customer financial data, is treated as privileged access and subject to the stronger controls set out in section 6.3.

5. Access to Networks and Network Services

Access to [Company]'s internal networks, cloud infrastructure and business applications is restricted to authorised users and devices, and is granted through the company's identity provider, Okta, wherever the system supports single sign-on (SSO). Multi-factor authentication (MFA) is required for all access to company systems, including remote access, cloud infrastructure and administrative interfaces. Network segmentation is used in the cloud environment to separate production systems from development and test systems, and access between segments is restricted to what is needed for each role.

6. User Access Management

[Company] manages user access through a formal lifecycle that covers the creation of an account when someone joins or changes role, the ongoing review of access while they remain with the company, and the prompt removal of access when access is no longer needed or the person leaves. Wherever possible, this lifecycle is driven through Okta and Microsoft 365 so that a single change to a person's status is reflected consistently across connected systems.

6.1 User Registration and Deregistration

Every individual who needs access to [Company]'s systems must have a unique account; shared or generic accounts are not permitted for personal use. Accounts are created only after a request has been raised and approved in line with section 6.6, and are linked to a named individual for the whole time they are in use. When an individual leaves [Company] or no longer needs an account, it must be deregistered in line with the timelines set out in section 6.5.

6.2 User Access Provisioning

Access is provisioned according to the role a person is assigned, using pre-defined role bundles wherever one exists for the job function. Provisioning must follow these requirements:

• Access requests must identify the system, the level of access needed and the business reason.
• New joiners are provisioned with the standard role bundle for their job function, set up through Okta and Microsoft 365 where those systems are used.
• Any request for access beyond the standard bundle for a role requires a separate approval from the relevant system or data owner.
• Access to customer data or production systems requires approval from the Head of Information Security or a person they have designated for that purpose.
• Every grant of access must be recorded, including who requested it, who approved it and when it was granted.

6.3 Management of Privileged Access

Privileged access, meaning access that allows configuration changes, the ability to grant access to others, or access to production data at scale, is limited to the smallest number of people needed to run the business. Administrators are given a separate account for administrative tasks wherever the underlying system supports it, so that day-to-day activity such as email and browsing is carried out on a standard account rather than a privileged one.

6.4 User Access Reviews

The Head of Information Security, or a member of the security team acting on their behalf, reviews privileged access every three months and reviews all other user access every six months, to confirm that each person still needs the access they hold and that it matches their current role. Access held by suppliers and support providers is reviewed at the same time as part of this exercise. Any access found to be excessive or no longer required is removed within five working days of the review.

6.5 Removal and Adjustment of Access Rights

Where a departure is involuntary, access must be disabled at once, before or at the point the individual is told of the decision. For all other leavers, access must be removed within one working day of the person's last working day. Where a person changes role, their previous access must be reviewed and any access no longer needed removed within five working days of the change. Accounts that have shown no login activity for 45 days are automatically disabled pending confirmation that they are still needed.

6.6 Access Provisioning, Deprovisioning and Change Procedure

Requests to grant, change or remove access, and the approvals and timelines that apply to each, follow the procedure set out in Appendix A.

6.7 Segregation of Duties

Where team size allows, the person who requests access, the person who approves it and the person who grants it in the system are three different individuals. In the security team, where staffing is limited, the same person may sometimes need to both approve and grant a request; in that case, every such grant is logged and is independently checked by a second member of the security team as part of the access reviews described in section 6.4. No single individual may both approve their own access request and grant it.

7. User Responsibility for Authentication Information

Every user is responsible for keeping their login credentials, security keys and MFA devices confidential, and must not share accounts, passwords or authentication devices with anyone else, including colleagues and IT support staff. Any suspected compromise of a password or authentication device must be reported to [Security contact email] as soon as it is discovered, so that the account can be secured.

7.1 Password Policy

Where a password is used as part of authentication, the following rules apply:

• Passwords must be at least 14 characters long.
• Multi-factor authentication is required in addition to a password for all company systems; where MFA is enforced, password complexity rules beyond minimum length are not required.
• Accounts are locked after 5 consecutive failed login attempts and must be unlocked by the identity provider or a member of the security team.
• Default passwords supplied with new systems or accounts must be changed before the account is used.
• Passwords must not be reused across [Company] systems and personal accounts.

8. System and Application Access

Access to individual systems and applications is controlled in addition to network-level access, so that a user's ability to reach a system does not by itself grant them the ability to use every function within it. Application-level permissions follow the same role-based model described in section 4.

8.1 Secure Log-on Procedures

Log-on to company systems requires a unique username, a password meeting the requirements in section 7.1, and MFA. Sessions on company systems and cloud consoles time out and require re-authentication after 15 minutes of inactivity. Failed log-on attempts do not reveal which part of the credential was incorrect, and successful log-on does not display more information about the account than is needed to confirm the user's identity.

8.2 Password Management System

Where [Company] systems store passwords, they are stored using strong, one-way hashing so that passwords cannot be recovered in plain text. Users are encouraged to use the password manager made available by the company rather than storing passwords in documents, spreadsheets or browsers without protection. Okta is used as the central identity store for company applications wherever supported, reducing the number of separate passwords users need to manage.

8.3 Use of Privileged Utility Programs

Tools capable of overriding normal system or application controls, such as database administration tools, cloud infrastructure consoles with elevated permissions, and scripting tools with broad system access, are restricted to individuals whose role requires them and who hold a separate privileged account as described in section 6.3. Use of these tools is logged, and logs are reviewed periodically by the security team as part of its monitoring activity.

8.4 Access to Program Source Code

Access to [Company]'s source code repositories is restricted to engineering staff who need it for their role, and is granted and removed through the same request and approval process as other system access. Write access to production branches requires a review and approval from another engineer before changes are merged, and repository access is included in the access reviews described in section 6.4.

9. Exceptions

Any exception to this policy must be requested in writing, must state the business reason and the proposed compensating control, and must be approved by the Head of Information Security. Exceptions are time-limited and are recorded and reviewed at the next scheduled access review.

10. Violations & Enforcement

Failure to comply with this policy, including sharing credentials, bypassing access controls or granting access without approval, is treated as a disciplinary matter and may result in disciplinary action up to and including termination of employment or contract, in line with [Company]'s disciplinary procedures. Suspected violations must be reported to [Security contact email].

11. Appendix A: Access Management Procedure

This appendix sets out the practical steps used to request, approve, change and remove access, supporting the requirements in sections 6.2 and 6.6.

11.1 Access Request and Approval Process

• The requester (the individual, their manager, or the HR system on a new joiner's behalf) raises an access request stating the system, the role or permission needed and the business reason.
• Standard role-based bundles are approved by the individual's manager; access beyond the standard bundle, or access to customer data or production systems, requires approval from the Head of Information Security or their designate.
• Once approved, access is granted by a member of the security team or an authorised system administrator, using Okta and Microsoft 365 as the point of provisioning wherever those systems are used.
• Every service account and API key must have a named individual owner responsible for its use and renewal, recorded at the time it is created.
• Every account held by a supplier or support provider must be given a defined end date at the time it is created, matching the length of the engagement.
• Where the normal approver is unavailable, the Head of Information Security may grant emergency access directly; such access is time-limited to a maximum of 24 hours, is logged, and is reviewed by another member of the security team within five working days.

11.2 Access Modification and Removal Process

• Where a person changes role, their manager must raise a request to adjust access within five working days of the change, and access no longer needed is removed within five working days of that request.
• Where a departure is involuntary, access is disabled at once, at or before the point the individual is told of the decision.
• For all other leavers, access must be removed within one working day of the person's last working day.
• Supplier and support provider accounts are disabled on or before the end date recorded when the account was created, and earlier if the engagement ends sooner.
• Accounts with no login activity for 45 days are disabled automatically pending confirmation that they are still required.
• All removals are recorded, including the account affected, the reason and the date removed, so that they can be checked as part of the reviews described in section 6.4.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Access Control Policy

• Version: 1.0
• Owner: Head of Security
• Approved by: Chief Executive Officer
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This policy defines how [Company] grants, manages, reviews, and removes access to its networks, systems, applications, and data. It exists to protect the personally identifiable information (PII) and health data that [Company] processes on behalf of the hospitals and health systems it serves as a HIPAA business associate, and to give staff, contractors, and auditors a clear, consistent record of who has access to what and why.

Controlling access is one of the most effective ways to reduce the risk of unauthorized disclosure, alteration, or loss of sensitive data. This policy supports [Company]'s obligations under HIPAA, SOC 2, and HITRUST, and works alongside the information security policy that sits above it.

2. Scope

This policy applies to all [Company] employees, contractors, and other workers who access [Company] systems, and to every system, application, network device, and cloud service that [Company] operates or manages, including those hosted on Microsoft Azure and accessed through Microsoft 365, whether used by staff working on-site or remotely under [Company]'s hybrid work arrangements.

3. Policy

[Company] grants access to networks, systems, and data only to authorized individuals and only to the extent needed for their role. Access must be requested, approved, provisioned, reviewed, and removed in line with the procedures in this policy, and every grant of access must be traceable to an approval and, where relevant, to the person who carried it out.

4. Access Control Model

[Company] uses role-based access control (RBAC) as its primary model. Access rights are grouped into role-based bundles tied to job functions (for example, engineering, customer support, or clinical product review), and individuals are granted the bundle that matches their role rather than having permissions assigned one at a time. This approach fits [Company]'s size and its planned hiring: as new employees join, they can be provisioned quickly and consistently by assigning the standard role bundle for their position, which reduces the risk of manual errors as headcount grows.

RBAC at [Company] is applied together with the principle of least privilege: every role bundle is built to include only the access needed to perform that role, and any request for access beyond a standard bundle must be justified and approved individually. Given that [Company] hosts its systems in the cloud and supports hybrid work, access decisions do not rely on network location; a user's identity, role, and device standing are what determine what they can reach.

5. Access to Networks and Network Services

Users may connect to [Company]'s networks and network services only where they have been explicitly authorized to do so. All access to [Company] cloud systems, including those hosted on Microsoft Azure, must go through the Microsoft 365 identity service, which enforces single sign-on and multi-factor authentication (MFA). Direct access to internal networks, administrative interfaces, or cloud consoles that bypasses the identity service is not permitted. Remote and hybrid workers must connect using company-managed devices and authenticate through the same identity service used on-site.

6. User Access Management

[Company] manages user access through a defined lifecycle covering registration, provisioning, privileged access, periodic review, and removal, so that access always reflects a person's current role and employment status.

6.1 User Registration and Deregistration

Every user must have a unique account tied to a single individual; shared or generic logins are not permitted for interactive use. Accounts are created when a person's employment or contract is confirmed by the HR system or, for contractors, by the engaging manager, and are created in the Microsoft 365 identity service, which is used as the single source of identity for downstream systems wherever integration allows. Accounts must be disabled or deleted when the corresponding registration record shows the person's access is no longer required.

6.2 User Access Provisioning

Access is provisioned according to the standard role bundle for the person's job function, with any additional access requiring separate approval.

• Access requests must be submitted by the person's manager or by the system owner, identifying the role bundle or specific systems needed.
• Requests must be approved by the relevant system owner or the Head of Security before provisioning takes place.
• Access is provisioned by the Head of Security or the security contractor, and a record of the grant (who requested it, who approved it, what was granted, and when) must be kept.
• Service accounts and API keys must have a named individual owner responsible for their use and rotation.
• Access granted to suppliers and support providers must include a fixed end date, not only a future review date; access is disabled automatically or manually once that date is reached unless renewed through a new approval.

6.3 Management of Privileged Access

Privileged access (accounts able to change system configuration, security settings, or other users' access, such as Microsoft 365 or Azure administrator roles) is granted only to the individuals who need it to perform their job and must be approved by the Head of Security. Wherever the underlying system supports it, administrators must use a separate account for administrative tasks and a standard account for day-to-day work such as email and document access.

6.4 User Access Reviews

The Head of Security must review all privileged access at least every quarter and all other user access at least every six months, confirming that each person's access still matches their current role. Access to systems and accounts held by suppliers and support providers must be reviewed at the same time as the privileged or standard access review, whichever applies, in addition to the end date set when access was granted. Reviews and any resulting changes must be documented.

6.5 Removal and Adjustment of Access Rights

When an employee or contractor leaves [Company], their access must be removed within 24 hours of their last working day. Where a departure is involuntary, or where [Company] otherwise judges the person to present a risk, access must be disabled immediately, at the time the decision is communicated, and before the individual is notified. Where a review or a change in role shows that a person no longer needs a particular access right, that right must be removed within 5 business days of the finding. Accounts that show no login activity for 45 consecutive days must be disabled pending confirmation from the person's manager that the account is still required.

6.6 Access Provisioning, Deprovisioning and Change Procedure

The step-by-step procedure for requesting, approving, granting, changing, and removing access is set out in Appendix A. All access changes, including emergency grants, must follow that procedure.

6.7 Segregation of Duties

Given the size of [Company]'s security function, the same individual (the Head of Security or, in their absence, the contractor) may sometimes need to both approve and provision an access request. Where this happens, the request and approval must still be recorded separately from the act of provisioning, and the Head of Security's own privileged access, along with a sample of other grants, must be reviewed by a more senior role, such as the Chief Executive Officer, as part of the quarterly privileged access review, to provide an independent check on activity the security function cannot separate from itself.

In the event that the normal approver is unavailable, a manager one level above the requester, or the Chief Executive Officer, may grant emergency access. Emergency access is limited to 24 hours, must be logged at the time it is granted, and must be reviewed by the Head of Security within 5 business days to confirm it was appropriate and to remove it if it is still active.

Because [Company] handles health data as a HIPAA business associate, it also maintains a separate emergency access procedure for reaching health data when normal access methods fail, such as during a system outage. Under this procedure, a designated on-call engineer may activate temporary emergency access to the affected system, all such access is logged automatically where the system supports it, and the Head of Security must review the log and confirm the access was appropriate within 2 business days of the emergency ending.

7. User Responsibility for Authentication Information

Users are responsible for keeping their passwords, MFA devices, and any other authentication information confidential and must not share them with anyone, including colleagues or managers. Users must report any suspected compromise of their credentials to the Head of Security immediately.

7.1 Password Policy

[Company] enforces the following minimum password requirements through the Microsoft 365 identity service:

• Minimum password length of 12 characters.
• MFA is required for all accounts, and is mandatory for all privileged and remote access.
• Accounts are locked after 5 consecutive failed login attempts and remain locked for 15 minutes or until unlocked by the Head of Security.
• Passwords must not be reused across the last 5 passwords used on the same account.
• Users are not required to change passwords on a fixed schedule; passwords must be changed immediately if compromise is suspected or confirmed.

8. System and Application Access

Access to [Company]'s systems and applications is granted only through the identity provider and only in line with the role bundle or specific approval described in Section 6. Direct local accounts on individual systems are avoided wherever the system can be integrated with the identity provider.

8.1 Secure Log-on Procedures

All systems handling PII or health data must enforce authentication through the Microsoft 365 identity service, including MFA, before granting access. Sessions handling PII or health data must time out and require re-authentication after 15 minutes of inactivity. Login attempts and failures must be logged, and error messages must not reveal whether a username, password, or account exists.

8.2 Password Management System

Where an application manages its own passwords rather than relying on the identity provider, it must enforce the same minimum length, lockout, and MFA requirements set out in Section 7.1, store passwords using a secure, one-way hashing method, and never display or transmit passwords in plain text.

8.3 Use of Privileged Utility Programs

Tools capable of overriding normal system or application controls, such as database administration tools, cloud administration consoles, or scripting utilities with elevated permissions, must be restricted to the individuals whose role requires them and must be accessed using a separate administrative account as described in Section 6.3. Use of these tools must be logged, and logs must be reviewed by the Head of Security as part of the quarterly privileged access review.

8.4 Access to Program Source Code

Access to source code for [Company]'s clinical decision support product and other software is restricted to engineering staff who need it to perform their role, is managed through the code repository's own access controls tied to the identity provider, and is reviewed as part of the standard access review described in Section 6.4. Changes to source code must go through the code review and change management process defined in [Company]'s software development policy.

9. Exceptions

Any exception to this policy must be requested from the Head of Security in writing, must state the reason for the exception and the compensating measure to be used instead, and must be time-limited and documented. Exceptions are reviewed at the next scheduled access review.

10. Violations & Enforcement

Any violation of this policy, including sharing credentials, bypassing approval steps, or retaining access no longer needed, may result in disciplinary action up to and including termination of employment or contract, and, where a supplier or business associate arrangement is involved, may result in termination of that arrangement. Suspected violations must be reported to the Head of Security at [Security contact email].

11. Appendix A: Access Management Procedure

This appendix sets out the step-by-step procedure for requesting, approving, changing, and removing access, supporting Section 6.6.

11.1 Access Request and Approval Process

• The requester (the new employee's manager, the contractor's engaging manager, or the system owner) submits the request, specifying the person, the system, and the role bundle or specific access needed.
• The relevant system owner or the Head of Security approves the request before any access is granted.
• The Head of Security or the security contractor provisions the access through the Microsoft 365 identity service or, where an integration is not available, directly in the target system.
• A record of the request, approval, and grant is kept, including the date access was provisioned.
• Emergency access requests follow the process in Section 6.7: they may be approved by a manager one level above the requester or the Chief Executive Officer, are limited to 24 hours, are logged at the time of the grant, and are reviewed by the Head of Security within 5 business days.

11.2 Access Modification and Removal Process

• Access changes triggered by a role change are requested by the person's manager and approved by the relevant system owner before being made.
• Access is removed within 24 hours of a leaver's last working day for standard departures.
• Access is removed immediately, at the time the decision is communicated, for involuntary departures or where [Company] identifies a risk.
• Access identified as unnecessary during a review is removed within 5 business days of that finding.
• Accounts inactive for 45 consecutive days are disabled pending manager confirmation.
• Supplier and support provider access is removed automatically or manually on the end date set when access was granted, unless a new approval extends it.
• All removals and modifications are recorded in the same manner as access grants, including who carried out the removal and when.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Access Control Policy

• Version: 1.0
• Owner: Chief Information Security Officer (CISO)
• Approved by: Chief Executive Officer
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

[Company] provides managed IT and security services to defense contractors and government agencies, and in doing so handles personally identifiable information (PII) and controlled unclassified information (CUI) on behalf of its customers. Because access to systems and data is one of the most direct ways that information can be exposed, lost, or misused, [Company] must control who can access its networks, systems, and applications, and under what conditions.

This policy sets out the rules for granting, reviewing, and removing access to [Company]'s systems and to customer environments it manages. It supports [Company]'s obligations under CMMC Level 2, NIST SP 800-171, and SOC 2, and works alongside [Company]'s information security policy.

2. Scope

This policy applies to all [Company] employees, contractors, interns, and third-party support personnel, and to every system, application, network, and data store that [Company] operates or manages, whether hosted in Azure Government, in another Microsoft 365 or Azure service, or on-premises. It covers standard user accounts, privileged (administrator) accounts, service accounts, API keys, and accounts issued to suppliers or support providers, regardless of whether the person or system is based on-site or works remotely under [Company]'s hybrid work model.

3. Policy

Access to [Company]'s systems and to customer environments must be granted only to identified, authorized individuals or services, only to the extent needed to perform their role, and must be reviewed and removed in a timely manner as roles or employment change. Every grant of access must be traceable to a specific request, approval, and business justification.

4. Access Control Model

[Company] uses role-based access control (RBAC) as its primary access control model. Access rights are grouped into roles that correspond to job functions (for example, service desk technician, SOC analyst, systems administrator, or account manager), and individuals are granted the role or roles that match their job rather than being given permissions one at a time. This approach fits a company of [Company]'s size and structure because it lets managers and administrators reason about access at the level of a job function, keeps access consistent across similar roles, and produces an auditable mapping between roles and permissions that supports CMMC and NIST SP 800-171 assessments.

RBAC is applied together with the principle of least privilege: a role must include only the access needed to perform that job, and no more. Where a system supports finer-grained conditions, such as restricting access by device compliance state, location, or customer environment, [Company] uses those controls to further reduce risk, particularly for access to customer CUI held in Azure Government.

5. Access to Networks and Network Services

Access to [Company]'s internal network, VPN, and administrative interfaces for on-premises systems must be restricted to authorized users and devices, and must require authentication through the Microsoft 365 identity service or an equivalent managed identity provider wherever the system supports it. Network access to customer environments, including Azure Government workloads, must be limited to the personnel assigned to that customer's account and must follow any additional access conditions set out in the customer contract. Direct access to production networks and to CUI-handling environments must not be granted without an approved access request.

6. User Access Management

Access to any [Company] or customer system must be requested, approved, and provisioned before it is granted, and every account, whether used by a person or by a service, must have an identifiable owner. [Company]'s identity and access management processes are administered primarily through the Microsoft 365 identity service, supplemented by system-specific access controls for on-premises and Azure Government resources that are not centrally managed by it.

6.1 User Registration and Deregistration

Every user must have a unique account; shared or generic logins are not permitted for interactive access. New accounts are created when the HR system or an authorized manager confirms a new hire, contractor engagement, or role change, and are created only after the access request has been approved as described in Appendix A. Accounts must be disabled promptly on departure or contract end, as set out in section 6.5.

6.2 User Access Provisioning

Access is provisioned according to the following requirements:

• Access must be requested using the standard access request process and approved by the requester's manager or the system/data owner before provisioning.
• Standard access is granted through predefined RBAC role bundles wherever a system supports them, rather than through one-off individual grants, so that access stays consistent as headcount grows.
• Access to customer environments must be limited to personnel assigned to that customer and must be recorded against the customer account.
• Service accounts and API keys must have a named individual owner responsible for their use, rotation, and eventual retirement, and must not be created without an approved request.
• Accounts issued to suppliers or support providers must have a defined end date that does not exceed the term of the relevant contract or engagement.
• New accounts must be reviewed for continued need if they remain unused for 45 days, and disabled if no business justification is found.

6.3 Management of Privileged Access

Administrative and other privileged access must be granted only where the role requires it and must be approved separately from standard access, following the process in Appendix A. Wherever the system supports it, administrators must use a separate account for administrative tasks, distinct from the account used for email, ticketing, and other day-to-day work, so that a compromise of one account does not automatically grant elevated rights.

6.4 User Access Reviews

The CISO's team must review privileged access, service accounts, and supplier or support accounts every quarter to confirm that each grant is still needed and that owners and end dates are current. Standard user access must be reviewed every six months. Reviews must be performed by someone other than the person whose access is being reviewed, and any access found to be unnecessary must be removed within 5 business days of the review.

6.5 Removal and Adjustment of Access Rights

Access must be adjusted whenever a person changes role, so that access tied to the previous role is removed and access matching the new role is granted through the standard request process. When a departure is involuntary, or when a person is found to pose a risk, access must be removed immediately, at the time the decision is made. For every other leaver, all access must be removed within 24 hours of the person's last working day. These figures apply to both [Company] systems and customer environments, including Azure Government.

6.6 Access Provisioning, Deprovisioning and Change Procedure

The detailed steps for requesting, approving, granting, changing, and removing access are set out in Appendix A. All requests, approvals, and removals must be recorded so that [Company] can demonstrate, on request, who approved a given access grant and when it was removed.

6.7 Segregation of Duties

Where staffing allows, the person who requests access, the person who approves it, and the person who provisions it in the system must be different individuals, and no one may approve their own access request. Where a team is too small to separate all three roles, for example within a single specialist function, the compensating control is that every grant of access is recorded and is checked in the next scheduled access review by someone who did not perform the original provisioning.

7. User Responsibility for Authentication Information

Every user is responsible for keeping their passwords, security keys, and multi-factor authentication (MFA) methods confidential, and must not share credentials, write them down in an accessible place, or reuse a [Company] password on any other site or service. Users must report a suspected compromise of their credentials to [Security contact email] immediately so that the affected account can be secured.

7.1 Password Policy

Passwords across [Company] and customer systems must meet the following minimum requirements:

• A minimum length of 14 characters for standard user accounts and 16 characters for privileged accounts.
• Passwords are not required to be changed on a fixed schedule; they must be changed immediately if compromise is suspected or confirmed.
• Multi-factor authentication is required for all access to the Microsoft 365 identity service, VPN, Azure Government resources, and any system holding CUI or PII.
• Accounts must be locked after 5 consecutive failed login attempts, and must remain locked for at least 15 minutes or until reset by an administrator.
• Default and vendor-supplied passwords must be changed before a system is put into use.

8. System and Application Access

Access to [Company]'s applications, service desk tooling (including its AI-assisted triage tool), ticketing systems, and customer-facing platforms must be authenticated individually and must reflect the role-based access described in section 4. Access to any system handling CUI must be limited to personnel who have completed the training and background requirements set for that work.

8.1 Secure Log-on Procedures

Systems must present a generic login prompt that does not reveal whether a username or system is valid before authentication succeeds, and must not display more information than necessary about a failed login attempt. Interactive sessions must lock automatically after 15 minutes of inactivity and require re-authentication to resume.

8.2 Password Management System

Where a system stores or manages passwords, it must store them using a strong, one-way cryptographic hash and must not display or transmit passwords in plain text. [Company] uses the Microsoft 365 identity service as its primary password and authentication management system, and requires equivalent protections for any on-premises or Azure Government system that manages its own credentials.

8.3 Use of Privileged Utility Programs

Tools capable of overriding normal system or application controls, such as database administration utilities, scripting engines, or infrastructure management tools, must be restricted to the administrators who need them for their role, accessed only through the separate administrative account described in section 6.3, and their use must be logged so the SOC team can review it.

8.4 Access to Program Source Code

Access to source code, scripts, and configuration used in [Company]'s internally developed tools and automations, including its service desk AI triage tool, must be restricted to the engineering and automation personnel who maintain them. Changes must go through version control with a record of who made the change, and code repositories must not be accessible to the general workforce.

9. Exceptions

Any exception to this policy, including a temporary deviation for a specific system or engagement, must be approved in advance by the CISO, documented with a reason and an expiry date, and reviewed at expiry to confirm it is either closed or re-approved.

10. Violations & Enforcement

Any violation of this policy, including sharing credentials, bypassing an approval step, or retaining access after it should have been removed, may result in disciplinary action up to and including termination of employment or contract, and may be reported to the affected customer where its data or environment is involved. The CISO's team is responsible for monitoring compliance with this policy and for investigating suspected violations.

11. Appendix A: Access Management Procedure

This appendix sets out the standard steps for requesting, approving, changing, and removing access to [Company] and customer systems, and provides an emergency route for use when the normal approver is unavailable.

11.1 Access Request and Approval Process

• The requester (the new hire's manager, the individual, or an automated trigger from the HR system) submits an access request identifying the system, the role or permission needed, and the business justification.
• The request is approved by the person's manager or by the relevant system or data owner; privileged access requests must also be approved by the CISO's team.
• Approved requests are provisioned by IT operations or the SOC team, using the predefined RBAC role bundle for the person's job function wherever one exists.
• Every request, approval, and grant is recorded, including the identity of the requester, approver, and person who provisioned the access.
• Where the normal approver is unavailable and access is needed urgently, the CISO or a designated deputy may grant emergency access; this access is time-limited to 24 hours, is logged, and is reviewed by the CISO's team within 5 business days to confirm it was appropriate and to remove it if it has not already expired.

11.2 Access Modification and Removal Process

• Role changes trigger a review of existing access, removal of access tied to the previous role, and provisioning of access matching the new role, following the approval steps above.
• Access is removed immediately when a departure is involuntary or when a person is found to pose a risk, and within 24 hours of the last working day for every other leaver.
• Service accounts, API keys, and supplier or support accounts are reviewed against their recorded owner and end date at each quarterly privileged access review, and are disabled if the owner cannot confirm continued need or the end date has passed.
• All removals are recorded, including the date access was removed and who performed the removal, so that [Company] can demonstrate compliance with the deadlines in this policy.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Access Control Policy

• Version: 1.0
• Owner: Chief Information Security Officer (CISO)
• Approved by: Chief Executive Officer
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This policy defines the rules by which [Company] grants, manages and removes access to its networks, systems, applications and data. It exists to ensure that people and automated processes can access only the information and systems they need to perform their role, and that access is granted, changed and removed in a controlled and auditable way.

[Company] processes personally identifiable information, financial data and sensitive personal data on behalf of enterprise customers across the United States, the United Kingdom, the European Union and India. Uncontrolled or excessive access to this data creates a risk of unauthorized disclosure, regulatory exposure and loss of customer trust. This policy supports [Company]'s information security policy and its obligations under ISO 27001, SOC 2, and applicable data protection laws, and it applies alongside those frameworks rather than replacing any control they separately require.

2. Scope

This policy applies to all [Company] employees, contractors, interns and third-party personnel who access [Company] systems, and to all systems that store, process or transmit [Company] or customer data, including infrastructure hosted on AWS, Microsoft Azure and Google Cloud, corporate and business applications connected to [Company]'s identity provider, and any system used from a [Company] office or a remote location under its hybrid working arrangements.

3. Policy

[Company] grants access to its systems and data only on the basis of a documented business need, following approval by an authorized approver, and grants no more access than is required to perform the relevant role. Access must be uniquely attributable to an individual or a named service, must be recorded in the identity provider or the relevant system, and must be reviewed, adjusted and removed in line with this policy. Shared or anonymous accounts are not permitted except where a documented exception under Section 9 applies.

4. Access Control Model

[Company] uses role-based access control (RBAC) as its primary model. Access to systems and data is assigned through defined roles that map to job functions, rather than granted to individuals on an ad hoc basis. RBAC is the right fit for a company of [Company]'s size because it allows access to be assigned and reviewed consistently across thousands of employees and multiple business units, reduces the risk of inconsistent one-off grants, and gives the security team a manageable, auditable structure to review against ISO 27001 and SOC 2 requirements.

RBAC is applied together with the principle of least privilege: every role is scoped to the minimum access needed for its function, and any access outside the standard role bundle must be individually requested and approved. Network access additionally follows a zero trust approach, meaning that no user or device is trusted by default based on network location alone; every request to a system or application must be authenticated and authorized regardless of whether it originates inside or outside a [Company] office.

5. Access to Networks and Network Services

Access to [Company]'s internal networks and network services is restricted to authorized users and devices and requires authentication through [Company]'s identity provider (Okta), with multi-factor authentication (MFA) enforced for all users. Remote and hybrid workers connect to internal resources through [Company]-approved secure connections; direct, unauthenticated access to internal network services from the public internet is not permitted. Network segmentation separates production cloud environments in AWS, Azure and Google Cloud from corporate office networks and non-production environments, and access between segments is controlled and logged.

6. User Access Management

[Company] manages user access through a defined lifecycle covering onboarding, changes of role ("movers"), and departure ("leavers"), supported by the HR system, Okta as the identity provider, and ServiceNow as the system of record for access requests and approvals.

6.1 User Registration and Deregistration

Every user account must be linked to a single, uniquely identifiable individual and created only after the HR system confirms a valid employment or contractor start record. Okta is the authoritative source for provisioning and de-provisioning access to connected applications. Accounts that remain unused for 30 consecutive days must be automatically disabled and investigated before being reinstated.

6.2 User Access Provisioning

Access is provisioned according to the following requirements:

• New access is granted based on a pre-defined role bundle tied to the individual's job function wherever one exists, rather than by copying another user's access.
• All access requests, including requests outside a standard role bundle, must be submitted and approved through ServiceNow before access is granted.
• The approver must be the requester's manager or the system/data owner, and must be a different person from whoever provisions the access wherever the team size allows this separation.
• Service accounts and API keys must have a named individual owner who is accountable for the account, a documented purpose, and a scheduled review.
• Accounts used by suppliers, contractors or support providers must have a defined end date at the time of creation, not only a future review date, after which access is automatically disabled unless renewed.
• Administrators must be issued a separate account for administrative tasks, distinct from their standard user account, wherever the system supports this.

6.3 Management of Privileged Access

Privileged access (accounts with administrative rights over systems, cloud environments, or security tools) is granted only after approval from the relevant system owner and the security team, is logged, and requires MFA at all times. Where the normal approver is unavailable, the CISO or a delegated member of the security team may grant emergency ("break-glass") access; such access is time-limited, automatically logged, and reviewed by the security team within five business days of use.

6.4 User Access Reviews

System and data owners, supported by the security team, must review privileged access every three months and all other user access every six months, confirming through ServiceNow that each access grant remains required. Service accounts, API keys, and supplier or support accounts are reviewed on the same schedule as privileged access. Any access found to be unnecessary during a review must be removed under Section 6.5.

6.5 Removal and Adjustment of Access Rights

Where an employee's departure is involuntary, all access must be removed immediately, at the time of notification. For all other leavers, access must be removed within 24 hours of the person's last working day. Where an employee changes role, access tied to the previous role must be removed within 5 business days of the change taking effect, and access for the new role provisioned in line with Section 6.2.

6.6 Access Provisioning, Deprovisioning and Change Procedure

The detailed steps for requesting, approving, modifying and removing access are set out in Appendix A (Section 11).

6.7 Segregation of Duties

[Company] separates the roles of access requester, approver and administrator to prevent any single individual from being able to grant themselves or others unauthorized access. No individual may approve their own access request, and system administrators must not approve access to systems they administer without an independent second approval. Where a role change would otherwise concentrate incompatible duties in one person, the security team must review and approve a compensating control before the change is made.

7. User Responsibility for Authentication Information

Every user is responsible for keeping their passwords, security keys and MFA devices confidential, for not sharing credentials with any other person, and for reporting suspected compromise of their credentials to the security team immediately, using [Security contact email].

7.1 Password Policy

[Company] requires the following minimum password standards for accounts that are not protected exclusively by single sign-on with MFA:

• Minimum length of 12 characters.
• Accounts are locked after 5 consecutive failed login attempts and remain locked until reset by the identity provider or the security team.
• MFA is required for all accounts accessing [Company] systems, in addition to any password requirement.
• Passwords must not be reused across [Company] systems or shared with other individuals.
• Default vendor or system passwords must be changed before a system is put into use.

8. System and Application Access

Access to [Company]'s systems and applications is controlled through Okta as the single point of authentication for connected applications, supplemented by native access controls within AWS, Azure and Google Cloud for infrastructure that is not integrated with Okta.

8.1 Secure Log-on Procedures

All systems must authenticate users before granting access and must not reveal, in a failed login attempt, whether a username or a password was incorrect. Sessions for privileged and administrative access time out after 15 minutes of inactivity; sessions for standard business applications time out after 30 minutes of inactivity. Successful and failed login attempts to critical systems are logged and retained in line with [Company]'s logging and monitoring requirements.

8.2 Password Management System

Where a password is required, the system must enforce the requirements in Section 7.1 at the point of creation or reset, and must store passwords using an approved cryptographic hashing method rather than in plain text. Secrets, credentials and API keys for service accounts must be stored in the secrets management capability provided by AWS, Azure or Google Cloud, and must not be stored in source code, configuration files, spreadsheets or messaging tools.

8.3 Use of Privileged Utility Programs

Tools capable of overriding normal system or application controls, such as operating system administration tools, database management utilities and cloud provider administrative consoles, are restricted to authorized administrators, require a separate privileged account under Section 6.3, and are logged and monitored by the security team.

8.4 Access to Program Source Code

Access to [Company]'s source code repositories is restricted to authorized engineering personnel and is managed through role-based permissions in the source code management system. Changes to production code require review and approval by a person other than the author before being merged, and direct write access to production branches is restricted to a limited set of authorized roles.

9. Exceptions

Any request to deviate from this policy must be submitted in writing to the CISO, must state the business justification and the duration of the exception, and must be approved before the deviation takes effect. Approved exceptions are logged and reviewed at least annually.

10. Violations & Enforcement

Failure to comply with this policy may result in disciplinary action up to and including termination of employment for employees, and termination of contract for contractors and third parties, in accordance with [Company]'s disciplinary procedures. Suspected violations must be reported to the security team at [Security contact email]. The security team may suspend access immediately where a violation poses an active risk to [Company] or customer data.

11. Appendix A: Access Management Procedure

This appendix sets out the practical steps that support the requirements in Section 6, from initial request through to removal or modification of access.

11.1 Access Request and Approval Process

• The requester (the individual, their manager, or an automated workflow triggered by the HR system) submits an access request through ServiceNow, specifying the system, the role or access level required, and the business justification.
• The request is routed to the designated approver, who must be the requester's manager or the relevant system or data owner.
• For privileged access, the request additionally requires approval from the security team.
• Once approved, a designated administrator, distinct from the approver wherever the team size allows, provisions the access in Okta or the relevant system.
• Every request, approval and grant is recorded in ServiceNow to provide an auditable history.

11.2 Access Modification and Removal Process

• Role changes are submitted through ServiceNow by the requester's manager and must result in removal of access tied to the previous role within 5 business days of the change taking effect.
• Where an employee's departure is involuntary, the HR system or the manager must notify the security team immediately, and all access must be removed at that time.
• For all other leavers, the HR system triggers removal of all access through Okta and connected systems within 24 hours of the person's last working day.
• Supplier, contractor and support accounts are disabled automatically on their pre-defined end date unless a renewal has been approved in advance.
• Access identified as unnecessary during a periodic review under Section 6.4 is removed within 5 business days of the review.
• All removals and modifications are logged in ServiceNow and are available for review by the security team.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.

[Company] Access Control Policy

• Version: 1.0
• Owner: IT Manager
• Approved by: Executive Director
• Effective date: [Effective date]
• Next review date: [Review date]

1. Purpose

This policy sets out who may access [Company]'s systems and data, and how that access is requested, approved, granted, reviewed, and removed. [Company] handles personal information belonging to donors and to vulnerable beneficiaries, as well as payment card data collected through online donations, and it must control access to that information carefully to protect the people it serves and to maintain their trust.

This policy sits beneath [Company]'s information security policy and applies its principles specifically to access control. It ensures that people and systems can reach only the information and functions they need to do their job or provide their service, and that access is removed promptly when it is no longer needed.

2. Scope

This policy applies to all [Company] staff, volunteers with access to any [Company] system, board members, contractors, and the outsourced IT and security provider, and covers every system that stores or processes [Company] data, including Microsoft 365 and any other software-as-a-service (SaaS) tool used to manage donors, beneficiaries, or online payments. It applies regardless of whether the person works on site or remotely.

3. Policy

Access to [Company] systems and data must be granted only following an approved request, must be limited to what a person or account needs to perform its function (the principle of "least privilege"), and must be reviewed on a regular schedule and removed promptly when no longer required. Every grant of access must be traceable to a request and an approval.

4. Access Control Model

[Company] uses role-based access control (RBAC). Under this model, access rights are attached to defined roles (for example, "finance staff," "program staff," "volunteer coordinator," or "system administrator") rather than to individuals, and a person is given the access that matches their role. This approach suits [Company]'s size and its use of Microsoft 365, because security groups can be configured to match these roles, keeping access consistent and easy to review without needing a large administrative team.

In practice, this means access to donor records, beneficiary case information, and payment-related systems is granted through group membership tied to a person's role, rather than through one-off individual grants. Least privilege is applied within this model: a role's access is set to the minimum needed for that function, and any request for access beyond a person's assigned role must be individually justified and approved.

5. Access to Networks and Network Services

[Company] does not operate its own internal network or infrastructure; all systems are accessed as SaaS applications, primarily through Microsoft 365. Access to these services requires authentication through the identity provider (Microsoft 365) and, where enabled, multi-factor authentication (MFA). Staff and volunteers working remotely or in the office (hybrid working) must connect using company-approved accounts and devices and must not share network credentials or access company systems through shared or public accounts.

6. User Access Management

[Company] manages user access through a consistent process of registration, provisioning, review, and removal, applied to staff, volunteers who use company systems, contractors, and non-human accounts such as service accounts and supplier accounts.

6.1 User Registration and Deregistration

Every individual who needs access to a [Company] system must have a unique account created through the identity provider (Microsoft 365); shared or generic logins are not permitted except where a system technically requires a shared account, in which case use must be logged and attributed to a named responsible person. Accounts must be created only after an approved request and deactivated as soon as they are no longer needed, following the process in Section 6.6.

6.2 User Access Provisioning

Access is provisioned according to the person's role and the principle of least privilege. The process must include:

• A request submitted by the person's manager, or by the volunteer coordinator for volunteers, specifying the systems and role needed.
• Approval by the IT Manager, or by the Executive Director for access to donor financial data, payment systems, or beneficiary case information.
• Provisioning carried out by the IT Manager or the outsourced IT provider, using Microsoft 365 security groups mapped to defined roles wherever possible.
• A record of every request, approval, and grant kept in an access register.

6.3 Management of Privileged Access

Privileged access (such as Microsoft 365 administrator roles) must be limited to the smallest number of people needed to run [Company]'s systems, approved by the Executive Director, and used through a separate administrative account distinct from the person's everyday account wherever the system supports this. Privileged access is reviewed quarterly.

6.4 User Access Reviews

The IT Manager, working with the outsourced IT provider, must review all privileged access every three months and all other user, volunteer, and supplier access every six months, checking that each account's access still matches the person's current role. Any access that is no longer justified must be corrected as part of the review.

6.5 Removal and Adjustment of Access Rights

Access must be adjusted whenever a person's role changes, and removed when they leave or are no longer authorized. Where a departure is involuntary, access must be revoked immediately, at or before the time the person is notified. For all other leavers, access must be removed within 5 business days of their last working day. Access to systems that store or process payment card data must be removed immediately for every leaver, regardless of the reason for departure. Supplier and support-provider accounts must be given an end date matching the contract term, not only a review date, and disabled on that date unless renewed. Accounts that show no activity for 45 days must be automatically disabled or flagged for review.

6.6 Access Provisioning, Deprovisioning and Change Procedure

The detailed steps for requesting, approving, granting, changing, and removing access are set out in Appendix A. All staff involved in access management must follow that procedure.

6.7 Segregation of Duties

Given [Company]'s size, the same person (typically the IT Manager, supported by the outsourced IT provider) may both request and technically grant access. To compensate for this, every access grant must be approved by a second person before it is actioned wherever the request involves privileged access, donor financial data, or payment systems, and every grant is logged in the access register for review during the periodic access reviews described in Section 6.4. An emergency access route exists for situations where the usual approver is unavailable: the Executive Director may authorize temporary access directly, such access must be time-limited to no more than 24 hours, and it must be logged and reviewed by the IT Manager as soon as practical afterward.

7. User Responsibility for Authentication Information

Every user is responsible for protecting their own login credentials. Users must not share passwords or accounts, must not write down or store passwords in an unprotected form, must enable MFA where it is offered, and must report any suspected compromise of their credentials to the IT Manager or outsourced IT provider immediately.

7.1 Password Policy

[Company] requires the following minimum password standards:

• Minimum length of 12 characters for all systems.
• For systems that store or process payment card data, passwords must contain both letters and numbers, in line with PCI DSS.
• MFA is required for all Microsoft 365 accounts and for all privileged and payment-related system accounts.
• Accounts are locked after 5 failed login attempts and remain locked for at least 30 minutes or until reset by the IT Manager or outsourced IT provider.
• Passwords must not be reused across different [Company] systems.
• Passwords do not need to be changed on a fixed schedule unless a compromise is suspected or confirmed.

8. System and Application Access

Access to individual applications, such as Microsoft 365, the donor management tool, and the online payment platform, must be gated through the identity provider using single sign-on where available, or through individually assigned credentials and MFA where single sign-on is not supported.

8.1 Secure Log-on Procedures

All systems must require MFA for log-on, particularly for remote and hybrid access. Sessions must time out after 30 minutes of inactivity on general systems and after 15 minutes of inactivity on systems that store or process payment card data. Log-on error messages must not reveal whether a username or password was the incorrect element, to avoid helping an attacker guess valid accounts.

8.2 Password Management System

Where a system allows it, [Company] must configure it to enforce the password and lockout standards in Section 7.1 automatically, rather than relying on users to apply them manually. Systems must store passwords in a hashed, non-readable form; the IT Manager must confirm this is the case for any new SaaS tool before it is adopted.

8.3 Use of Privileged Utility Programs

Tools capable of overriding normal access controls, such as the Microsoft 365 admin center, tenant-wide configuration settings, or bulk data export functions, must be restricted to accounts with privileged access as defined in Section 6.3. Use of these tools must be logged, and logs must be reviewed by the IT Manager or outsourced IT provider as part of the quarterly privileged access review.

9. Exceptions

Any request to deviate from this policy must be approved in advance by the IT Manager, documented with the reason and a compensating control, time-limited, and reviewed by the Executive Director where it involves donor financial data, beneficiary case information, or payment systems.

10. Violations & Enforcement

Failure to comply with this policy may result in suspension or removal of access, disciplinary action up to and including termination of employment or volunteer engagement, and termination of contract for suppliers or support providers. Suspected violations must be reported to the IT Manager and handled in line with [Company]'s incident response process.

11. Appendix A: Access Management Procedure

This appendix sets out the practical steps [Company] follows to request, approve, grant, change, and remove access, supporting Section 6.6.

11.1 Access Request and Approval Process

• The requesting manager, or the volunteer coordinator for volunteers, submits an access request specifying the person, role, and systems needed.
• The IT Manager checks the request against the standard access matching that role.
• The Executive Director approves any request involving privileged access, donor financial data, payment systems, or beneficiary case information; the IT Manager approves standard, non-sensitive requests.
• The IT Manager or the outsourced IT provider provisions the access through the identity provider (Microsoft 365), using existing security groups where possible.
• Every request, approval, and grant is recorded in the access register, including the name of the requester, approver, and administrator who actioned it.
• Service accounts and API keys must be requested with a named individual owner responsible for the account, recorded in the access register alongside human user accounts.

11.2 Access Modification and Removal Process

• A role change must trigger a request from the person's manager to adjust access within 5 business days of the change taking effect, removing access no longer needed for the new role.
• For an involuntary termination, the manager or Executive Director notifies the IT Manager immediately, and access is revoked at or before the time the person is informed.
• For a voluntary resignation, retirement, or other planned departure, the manager notifies the IT Manager of the last working day in advance, and access is removed within 5 business days of that date.
• For all leavers, access to any system that stores or processes payment card data is removed immediately, regardless of the reason for departure.
• Supplier and support-provider accounts are disabled on the contract end date recorded at the time access was granted, unless the contract has been renewed and the record updated.
• Access flagged as unnecessary during a periodic review (Section 6.4) must be removed within 5 business days of the review.

Disclaimer

This document is provided for informational purposes only and does not constitute legal advice. It is provided "as is", without warranty of any kind, express or implied, and no liability is accepted for any loss or damage arising from its use. It is used at your own discretion. Review it with a qualified adviser before adopting it.