The following article contains guidance explaining portions of the System Access Control Policy that we frequently see questions around, explaining what the sections mean.
Guidance statements will appear in bold and enclosed in brackets “[]” below the statements of the policy.
System Access Control Policy
[COMPANY NAME]
______________________________________________________________________
Background
Access to [COMPANY NAME] systems and applications is limited for all users, including but not limited to workforce members, volunteers, business associates, contracted providers, and consultants. Access by any other entity is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized use or access of the organization's information systems.
Purpose
The purpose of this procedure is to provide a policy and guideline for creating, modifying, or removing access to the company’s network and data by creating, changing or deleting the network account configuration for a User.
Scope
This policy and defined process is used to allow access to the company’s data and systems to individuals who meet the requirements defined in this policy. This policy governs individuals who are granted access that is necessary to support the business. This policy relates to all data used, processed, stored, maintained, or transmitted in and through the company’s systems.
Policy
Access Establishment and Modification - Role-Based
Requests for access to [COMPANY NAME] Platform systems and applications are made formally using the following process:
A [COMPANY NAME] workforce member initiates the access request by creating an Issue in the [COMPANY NAME] ticketing system.
[A ticketing system is not required for this documentation, but is recommended for auditability.]
User identities must be verified prior to granting access to new accounts.
Identity verification must be done in person where possible; for remote employees, identities must be verified over the phone.
For new accounts, the method used to verify the user's identity must be recorded on the Issue.
[Identity verification over the phone or another method such as Zoom and recording this verification are not required, but are recommended as a security best practice.]
The Security Officer will grant or reject access to systems as dictated by the employee's role and job title.
If additional access is required outside of the minimum necessary to perform job functions, the requester must include a description of why the additional access is required as part of the access request.
If the request is rejected, it goes back for further review and documentation.
If the review is approved, the request is marked as “Done”, and any pertinent notes are added.
Access Reviews
All access to [COMPANY NAME] systems and services is reviewed and updated on <FREQUENCY OF ACCESS REVIEWS> basis to ensure proper authorizations are in place commensurate with job functions. The process for conducting reviews is outlined below:
The Security Officer initiates the review of user access by creating an Issue in the [COMPANY NAME] Ticketing System
The Security Officer is assigned to review levels of access for each [COMPANY NAME] workforce member.
If user access is found during review that is not in line with the least privilege principle, the Security Officer may modify user access and notify the user of access changes.
Once the review is complete, the Security Officer then marks the ticket as “Done”, adding any pertinent notes required.
[Annual access reviews are the industry standard, though for some levels of access such as users with administrative privileges, these may be performed more frequently.]
[Security Officer is a suggested role in this instance. You can change this role to whoever will be performing this function at your organization.]
Workforce Clearance
The level of security assigned to a user to the organization's information systems is based on the minimum necessary amount of data access required to carry out legitimate job responsibilities assigned to a user's job classification.
All access is regulated by the role-based access control (RBAC) method, based on the Principle of Least Privilege.
[COMPANY NAME] maintains a least privilege approach for access to customer data.
[This section is saying that you have defined access for different job roles by default. For example, it would be standard for a developer/software engineer to have write access to your source code repositories, but would be non-standard access for someone in HR or Finance to have that level of access. Someone in HR or Finance would require an additional documented approval to receive that level of access.]
Unique User Identification
Access to the [COMPANY NAME] Platform systems and applications is controlled by requiring unique User Login IDs and passwords for each individual user and developer.
Passwords requirements mandate strong password controls.
Passwords are not displayed at any time and are not transmitted or stored in plain text.
Default accounts on all production systems, including root, are disabled.
Shared accounts are not allowed within [COMPANY NAME] systems or networks.
[Shared accounts should be forbidden where possible. In some instances, this may not always be possible in which case this bullet point should be updated.]
Automated log-on configurations other than the company’s approved Password Management provider that store user passwords or bypass password entry are not permitted for use with [COMPANY NAME] workstations or production systems.
Identifiers will include user characteristics and status to help further identify the individual, such as employment status (e.g., contractor, non-organizational users).
Automatic Logoff
Users are required to make information systems inaccessible by any other individual when unattended by the users (ex. by using a password protected screen saver or logging off the system).
Concurrent Sessions
[COMPANY NAME] limits the number of concurrent sessions, as follows:
Ex. Account X: <MAX # OF SESSIONS>
Ex. Accounts Type A: <MAX # OF SESSIONS>
Disabling Accounts
In order to mitigate risk, user accounts will be disabled as outlined in Appendix A.
[The Concurrent Sessions and Disabling Accounts sections are only required for NIST 800-53, for SOC 2 and ISO 27001 they may be removed.]
Employee Workstation Use
All workstations at [COMPANY NAME] are company owned, and all are laptop products running Windows, Mac OSX or Linux.
[This section may be edited if your organization relies on BYOD machines instead of company-owned computers. For additional guidance on BYOD machines, please refer to this help article: https://help.drata.com/en/articles/6297649-how-do-bring-your-own-device-byod-devices-affect-my-audit]
Workstations may not be used to engage in any activity that is illegal or is in violation of company policies.
Access may not be used for transmitting, retrieving, or storage of any communications of a discriminatory or harassing nature or materials that are obscene or "X-rated". Harassment of any kind is prohibited. No messages with derogatory or inflammatory remarks about an individual's race, age, disability, religion, national origin, physical attributes, sexual preference, or health condition shall be transmitted or maintained. No abusive, hostile, profane, or offensive language is to be transmitted through the organization's system.
Information systems/applications also may not be used for any other purpose that is illegal, unethical, or against company policies or contrary to the company's best interests. Messages containing information related to a lawsuit or investigation may not be sent without prior approval.
Solicitation of non-company business, or any use of the company's information systems/applications for personal gain is prohibited.
Users may not misrepresent, obscure, suppress, or replace another user's identity in transmitted or stored messages.
Workstation hard drives must be encrypted
All workstations have firewalls enabled to prevent unauthorized access unless explicitly granted.
Employee Termination/Offboarding Procedures
The Human Resources Department (or other designated department), users, and their supervisors are required to notify the Security Officer upon completion and/or termination of access needs and facilitate completion of the "Termination Checklist".
The Human Resources Department, users, and supervisors are required to notify the Security Officer to terminate a user's access rights if there is evidence or reason to believe the following (these incidents are also reported on an incident report and is filed with the Privacy Officer):
The user has been using their access rights inappropriately;
A user's password has been compromised (a new password may be provided to the user if the user is not identified as the individual compromising the original password);
The Security Officer will terminate users' access rights within <SLA FOR SEPARATION> of termination/separation, and will coordinate with the appropriate [COMPANY NAME] employees to terminate access to any non-production systems managed by those employees.
[Within 1 business day is the standard separation SLA.]
The Security Officer audits and may terminate access of users that have not logged into the organization's information systems/applications for an extended period of time.
[The roles listed in this section such as HR, Security Officer, and Privacy Officer are suggested roles in this instance. You can change these roles to whoever will be performing these functions at your organization.]