Access Control Policy

Purpose

To limit access to company information and information processing systems, networks, apps, and facilities to authorized parties in accordance with business objectives.

Scope

This policy applies to:

• All production systems processing customer data
• Development and staging environments containing production data
• Corporate systems and applications (Google Workspace, GitHub, AWS, etc.)
• Physical and virtual infrastructure supporting business operations
• All employees, contractors, and third-party users with system access

Data Classification: This policy covers all data classified as Confidential, Restricted, or containing Personally Identifiable Information (PII).

Small Team Implementation Notes

For organizations with fewer than 10 employees:

• CEO or CTO may serve as default approver for access requests
• Combined roles (e.g., Security Delegate + System Administrator) are acceptable
• Automated workflows may be implemented as the organization grows
• Documentation requirements remain the same regardless of team size

Policy

• Access to the company's computing resources and information is restricted to employees who have a legitimate business need for this access.
• Access rights shall be granted or revoked in accordance with this Access Control Policy.
• Access granted and revoked shall be documented.

Business Requirements of Access Control

Access Control Policy

The company shall determine the type and level of access granted to individual users based on the principle of least privilege. This principle states that users are only granted the level of access absolutely required to perform their job functions, and is dictated by the company's business and security requirements. Permissions and access rights not expressly granted shall be, by default, prohibited.

The company's primary method of assigning and maintaining consistent access controls and access rights shall be through the implementation of Role-Based Access Control (RBAC). Wherever feasible, rights and restrictions shall be allocated to groups. Individual user accounts may be granted additional permissions as needed with approval from the system owner or authorized party.

All privileged access to company production infrastructure shall use Multi-Factor Authentication (MFA) when available.

Access to Networks and Network Services

The following security standards shall govern access to company networks and network services:

• Technical access to company networks must be formally documented including the standard role or approver, grantor, and date
• Only authorized company employees and contractors, with a business need, shall be granted access to the company production networks and resources
• Company guests may be granted access to company guest networks after registering with office staff without a documented request
• Remote connections to company production systems and networks must be encrypted

Service Account Management

Service accounts used for application-to-application communication and automated processes shall be managed as follows:

• Documented business justification and owner identification
• Minimum necessary privileges for intended function
• Regular review of access rights and necessity (quarterly)
• Secure credential storage (no hardcoded passwords in source code)
• Monitoring and logging of service account activities
• Immediate revocation when no longer needed

User Access Management

The company requires that all personnel have a unique user identifier for company system access and that user credentials and passwords are not shared between multiple personnel. Users with multiple levels of access (e.g. administrators) should be given separate accounts for normal system use and administrative functions wherever feasible. Root, service, and administrator accounts may use a password management system to share passwords for business continuity purposes only. Administrators shall only use shared administrative accounts as needed. If a password is compromised or suspected of compromise the incident should be escalated to the Security Delegate immediately and the password must be changed.

User Registration and Deregistration

Only authorized administrators shall be permitted to create new company user IDs, and may only do so upon receipt of a documented request from authorized parties. User provisioning requests must include approval from data owners or company management authorized to grant system access. Before account creation, administrators should verify that the account does not violate any company security or system access control policies such as segregation of duties, fraud prevention measures, or access rights restrictions.

Company user IDs shall be promptly disabled or removed when users leave the organization or contract work ends in accordance with SLAs. User IDs shall not be re-used.

User Access Provisioning

• New employees and/or contractors are not to be granted access to any company production systems until after they have completed all HR onboarding tasks, which may include but are not limited to the signed employment agreement, intellectual property agreement, security awareness training, and acknowledgment of the company's information security policy
• Access should be restricted to only what is necessary to perform job duties
• No access may be granted earlier than the official employee start date unless personnel have completed above referenced on-boarding tasks.
• Access requests and rights modifications shall be documented in an access request ticket or email. No permissions shall be granted without approval from the system, data owner or management
• Records of all permission and privilege changes shall be maintained for no less than one year

Management of Privileged Access

The company shall ensure that the allocation and use of privileged access rights are restricted and managed judiciously. The objective is to ensure that only authorized users, software components, and services are granted privileged access rights.

The company will ensure that access and privileges conform to the following standards:

• Identify and Validate Users: Identify users who require privileged access to each system and process.
• Assign Privileged Access: Grant access rights based on individual needs and qualifications, ensuring strict compliance with the access control policy.
• Maintain Authorization Protocols: maintain records of all privileged access allocations.
• Enforce Strong Authentication: Require MFA for all privileged access when available.
• Prevent Generic Admin ID Usage: prevent the usage of generic administrative user IDs
• When feasible, Adopt Time-Bound Access Protocols: Grant privileged access only for the necessary duration required to accomplish specific tasks and revoke once the task is completed.
• Ensure Logging and Auditing: Log all privileged logins and activity
• When feasible, Uphold Distinct and Separate Identities: Preserve distinct identities for privileged access rights and ensure such identities are neither shared among multiple users nor used for routine, non-administrative tasks.

User Access Reviews

Administrators shall perform access rights reviews of user, administrator, and service accounts on a quarterly basis to verify that user access is limited to systems that are required for their job function. Access reviews shall be documented.

Access reviews may include group membership as well as evaluations of any specific or exception-based permission. Access rights shall also be reviewed as part of any job role change, including promotion, demotion, or transfer within the company.

Removal & Adjustment of Access Rights

The access rights of all users shall be promptly removed upon termination of their employment or contract, or when rights are no longer needed due to a change in job function or role. The maximum allowable time period for access termination is 24 business hours.

Access Provisioning, Deprovisioning, and Change Procedure

The Access Management Procedure for company systems can be found in Appendix A to this policy.

Segregation of Duties

When feasible, conflicting duties and areas of responsibility shall be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of company assets. When provisioning access, care should be taken that no single person can access, modify or use assets without authorization or detection. The initiation of an event should be separated from its authorization when feasible. The possibility of collusion should be considered when determining access levels for individuals and groups.

User Responsibility for the Management of Secret Authentication Information

Control and management of individual user passwords is the responsibility of all company personnel and third-party users. Users shall protect secret authentication information in accordance with the Information Security Policy.

Password Policy

Primary authentication method should be Single Sign-On (SSO) through Google Workspace. For systems requiring separate credentials:

• Minimum 12 characters, one upper case, one number OR use of approved password manager
• Systems shall be configured to remember and prohibit reuse of passwords for the last 8 passwords used
• Passwords shall be set to lock out after 6 failed attempts.
• Initial passwords must be set to a unique value and changed after first login
• For manual password resets, a user's identity must be verified prior to changing passwords
• Do not use secret questions (place of birth, etc) as a sole password reset requirement
• Require email or chat tool verification of a password change request
• Require the current password in addition to the new password during password change
• Store passwords in a hashed and salted format
• Enforce appropriate account lockout and brute-force protection on account access

System and Application Access

Information Access Restriction

Applications must restrict access to program functions and information to authorized users and support personnel in accordance with the defined access control policy. The level and type of restrictions applied by each application should be based on the individual application requirements, as identified by the data owner. The application-specific access control policy must also conform to company policies regarding access controls and data management.

Prior to implementation, evaluation criteria are to be applied to application software to determine the necessary access controls and data policies. Assessment criteria include, but are not limited to:

• Sensitivity and classification of data.
• Risk to the organization of unauthorized access or disclosure of data
• The ability to, and granularity of, control(s) on user access rights to the application and data stored within the application
• Restrictions on data outputs, including filtering sensitive information, controlling output, and restricting information access to authorized personnel
• Controls over access rights between the evaluated application and other applications and systems
• Programmatic restrictions on user access to application functions and privileged instructions
• Logging and auditing functionality for system functions and information access
• Data retention and aging features

All unnecessary default accounts must be removed or disabled before making a system available on the network. Specifically, vendor default passwords and credentials must be changed on all company systems, devices, and infrastructure prior to deployment. This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, and Simple Network Management Protocol (SNMP) community strings where feasible.

Secure Log-on Procedures

Secure log-on controls shall be designed and selected in accordance with the sensitivity of data and the risk of unauthorized access based on the totality of the security and access control architecture.

Password Management System

Systems for managing passwords should be interactive and assist company personnel in maintaining password standards by enforcing password strength criteria including minimum length, and password complexity where feasible.

All storage and transmission of passwords is to be protected using appropriate cryptographic protections.

Use of Privileged Utility Programs

Use of utility programs, system files, or other software that might be capable of overriding system and application controls or altering system configurations must be restricted to the minimum personnel required. Systems are to maintain logs of all use of system utilities or alteration of system configurations. Extraneous system utilities or other privileged programs are to be removed or disabled as part of the system build and configuration process.

Security Delegate approval is required prior to the installation or use of any ad hoc or third-party system utilities.

Access to Program Source Code

Access to program source code and associated items, including designs, specifications, verification plans, and validation plans shall be strictly controlled in order to prevent the introduction of unauthorized functionality into software, avoid unintentional changes, and protect company intellectual property.

All access to source code shall be based on business needs and must be logged for review and audit.

Exceptions

Requests for an exception to this Policy must be submitted to the Security Delegate for approval.

Violations & Enforcement

Any known violations of this policy should be reported to the Security Delegate. Violations of this policy can result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment.

APPENDIX A – Access Management Procedure

1. Pre-Start Requirements
   1. Signed employment/contractor agreement completed
   2. Background check completed (if required for role)
   3. Security acknowledgment signed
2. Access Provisioning (First Day)
   Responsible Party: CTO or designated technical lead
   Standard Employee Access:
   1. Google Workspace account creation
   2. GitHub organization invitation
   3. Necessary development environment access
   4. Slack workspace invitation
   5. Password manager invitation
3. Role-Specific Access:
   1. Production system access (engineering roles only)
   2. AWS console access (senior engineering roles)
   3. Administrative privileges (leadership approval required)
4. Contractor Access Procedure
   Responsible Party: CTO with CEO approval for production access
   1. Temporary Google Workspace account with contract end date
   2. Limited GitHub collaborator access to specific repositories
   3. No production system access unless explicitly justified and approved
   4. Access documented in contractor tracking spreadsheet
5. Access Modification Procedure
   1. Email or Slack request to CTO with business justification
   2. CEO approval required for administrative or production access changes
   3. Changes implemented within 2 business days
   4. Access change logged in access tracking document
6. Offboarding Procedure
   Responsible Party: CTO (immediate notification by CEO/HR function)
   Immediate Actions (within 24 hours):
   1. Disable Google Workspace account
   2. Remove from GitHub organization
   3. Revoke AWS access
   4. Remove from Slack workspace
   5. Collect company devices/access cards
   6. Reset any shared passwords the person had access to
7. Documentation:
   1. Complete offboarding checklist
   2. Confirm all access revoked
   3. Update access tracking records
8. Quarterly Access Review Procedure
   Responsible Party: CTO with CEO oversight
   Process:
   1. Export user lists from all systems (Google Workspace, GitHub, AWS, etc.)
   2. Review each account for continued business need
   3. Verify MFA status for all accounts
   4. Document review findings
   5. Remove or modify access as needed
   6. File quarterly review documentation
9. Emergency Access Procedure
   1. After-hours emergencies: CTO approval via phone/text
   2. CEO approval required for production access emergencies
   3. Emergency access must be documented within 24 hours
   4. Temporary emergency access expires after 72 hours unless formally approved

Document History

Version	Date	Description	Written by	Approved by
1.0.0	6/13/25		Dominick Pham	Adam Boender