AUTH-18 Company Confidential Systems Access Review

What is AUTH-18 Company Confidential Systems Access Review Control?

Company Confidential Systems Access Review is a way to periodically check and verify that users have the correct level of access to systems, applications, and data based on their job functions and responsibilities. The purpose of this review is to identify any unauthorized access, unnecessary access, or segregation of duties conflicts and then take corrective action to mitigate any risks.

The user access reviews involve managers or supervisors reviewing and certifying the access rights of their direct reports. This process ensures that only authorized personnel have access to the organizational resources, helping to prevent data breaches, unauthorized access, and compliance violations. It also helps to keep track of changes in the organization’s structure, such as employees leaving or changing roles, to ensure that access rights are revoked or modified accordingly.

Overall, user access reviews play a critical role in maintaining the security of an organization’s systems and data, ensuring compliance with regulatory requirements, and managing the risk associated with unauthorized access.

Ideally, this control should be performed frequently, especially for organizations that experience a lot of change. The frequency can be determined based on the criticality of the system under review. A critical or sensitive system hosting a lot of sensitive information needs to be reviewed frequently, whereas a low-risk system can be reviewed less frequently but at least annually. The decision is up to each organization.

At Trust Cloud, we made it easier for organizations to make this decision by grouping sensitive systems together and less critical systems together. Each organization can then choose the frequency according to the group.

The controls referred to here are:

• AUTH-16: This is for critical systems; this group should have their review done frequently (i.e., weekly, monthly, or quarterly) depending on the volume of activity.
• AUTH-17: This is for less sensitive systems; this group should also have their review done frequently (i.e., monthly or quarterly) depending on the volume of activity.
• AUTH-18: This is for low-risk systems; this group should also have their review done at least annually, depending on the volume of activity.

Available tools in the marketplace

The following listing is “crowdsourced” from our customer base or from external research. TrustCloud does not personally recommend any of the tools below, as we haven’t used them.

Managing Access Authorization Tools

Secure Compliance Corp

SecurEnds

Available templates

TrustCloud has a curated list of templates, internally or externally sourced, to help you get started. Click on the link for a downloadable version:

• N/A: No template recommendation is made for this control.

Control implementation

To implement this control,

1. Define the review process and what it entails. At a minimum, it should include the following steps:
   1. Define the scope. Identify the systems, applications, and data that need to be included in the access review. Determine the frequency of the review, such as quarterly or annually.
   2. Identify the reviewers. Select the individuals who will review and certify the access rights of the users. Typically, this involves the system administrator, managers, or supervisors who are responsible for their team’s access rights.
   3. Gather information: Collect information about the users’ access rights to the identified systems, applications, and data. This may involve running reports or using automated tools to capture the user’s access details.
   4. Review access rights: Review the user’s access rights to ensure they are appropriate, necessary, and comply with the organization’s policies and regulations. This includes verifying that access rights are aligned with the user’s job function and responsibilities.
   5. Remediation: If any access rights are found to be unnecessary or inappropriate, take corrective action to remove or modify access rights. This may involve updating user roles or revoking access to specific systems or applications. You may need to provide proof of remediation for an audit. Whether this is in a ticketing system or document, be ready to provide it.
   6. Certification: The reviewers must certify that the users’ access rights have been reviewed and verified. This certification process ensures that the organization has taken reasonable measures to manage access rights and reduce the risk of unauthorized access.
   7. Documentation: Document the access review process, including the scope, findings, and remediation actions. This documentation provides evidence of the organization’s efforts to manage access rights and comply with regulatory requirements.
2. Document the review process and frequency in a policy. This can be within an existing policy (i.e., the Information Security Policy) or in a new policy.
3. Perform the review as outlined in a policy and retain documentation.

What evidence do auditors look for?

Most auditors, at a minimum, are looking for documentation that is documented within a ticketing system, along with:

1. Provide documentation that is documented within a ticketing system, along with:
   1. The user access listing reviewed
   2. The remediation proof, if there were any
   3. The certification from the reviewer

Evidence example

For the suggested action, an example is provided below:

1. Provide documentation that is documented within a ticketing system, along with:
   1. The user access listing reviewed
   2. The remediation proof, if there were any
   3. The certification from the reviewer

The following screenshot shows a user request ticket showing the time period during which the review was done for a number of systems for the same assignee.

The following screenshot shows a ticket showing that for each system in review, a separate ticket was created that contained the user listing, the remediation, if any, and the certification.

The following screenshot shows an individual ticket containing, in the attachment, the user listing and the certification in the description.

NOTE: This is just an example of documentation. The certification can be done in many ways (i.e., the user list can be exported to Excel, with certification and remediation happening there).