Policy Owner: CISO
Effective Date: May 8, 2026
Reviewed: Annually
Next Review: May 8, 2027
Effective Date: May 8, 2026
Reviewed: Annually
Next Review: May 8, 2027
Purpose
To limit access to information and information processing systems, networks, and facilities to authorized parties in accordance with business objectives.Scope
All Neuroscale information systems that process, store, or transmit confidential data as defined in the Data Management Policy. Applies to all Neuroscale employees and external parties with access to Neuroscale networks and system resources.Access control policy
Access to information computing resources is limited to personnel with a business requirement for such access. Access rights shall be granted or revoked in accordance with this policy. Neuroscale follows the principle of least privilege: users are granted only the level of access required to perform their job functions. Permissions not expressly granted are prohibited by default. The primary method of assigning and maintaining access is Role-Based Access Control (RBAC). Where feasible, rights are allocated to groups; individual accounts may be granted additional permissions with system-owner approval. All privileged access to production infrastructure must use Multi-Factor Authentication (MFA).Access to networks and network services
- Technical access must be formally documented including the role/approver, grantor, and date.
- Only authorized Neuroscale employees and third parties working under a signed contract or SOW, with a business need, are granted access to production networks and resources.
- Guests may be granted guest-network access after their visit is sponsored by an employee.
- Remote connections to production must be encrypted.
Customer access management
When configuring cross-account access using AWS IAM roles, Neuroscale generates the external ID — never use a customer-provided value. External IDs must be unique per customer and not editable by the customer. Re-using external IDs across customers does not solve the confused-deputy problem.User access management
All personnel must have a unique user identifier. Credentials are not shared. Users with multiple privilege levels (e.g., admins) should have separate accounts for normal and administrative use. Root, service, and admin accounts may use a password manager only for business-continuity purposes; admins use shared admin accounts only as needed. Compromised passwords are escalated to security@neuroscale.ai immediately and the password is changed.Registration and deregistration
Only authorized administrators create new user IDs, and only on receipt of a documented request from authorized parties. Provisioning requests require approval from data owners or management. Before account creation, admins verify the request does not violate segregation-of-duties or other access-control rules. User IDs are promptly disabled or removed when users leave the organization or contract work ends, in accordance with SLAs. User IDs are not re-used.Provisioning
- New employees and contractors are not granted access to production systems until HR onboarding is complete (signed employment agreement, IP agreement, acknowledgement of the Information Security Policy).
- Access is restricted to what is necessary for the role.
- No access may be granted before the official start date.
- Requests and modifications are documented in Linear (the “Access” team queue).
- Records of permission and privilege changes are retained for at least one year.
Privileged access
- Identify and validate users requiring privileged access for each system.
- Allocate privileges based on need and the access-control policy.
- Maintain records of all privileged-access allocations.
- Require MFA for all privileged access.
- Prevent generic admin-ID use.
- Time-bound privileged access where practical; revoke once the task is done.
- Log all privileged logins and activity.
- Maintain distinct identities for privileged access — never share, never use for routine work.
Access reviews
Administrators perform access-rights reviews of user, administrator, and service accounts on a quarterly basis to verify access is limited to systems required for the user’s job function. Each cycle is documented in a per-quarter Linear project under the Access Reviews team (the current cycle’s project is the most recently createdAccess Reviews - QnYnn and RBAC Review - QnYnn pair).
Access rights are also reviewed as part of any role change — promotion, demotion, transfer.
See the Access Reviews procedure.
Removal & adjustment
Access rights are removed promptly upon termination of employment or contract, or when no longer needed. Maximum allowable time for access termination: 24 business hours.Provisioning, deprovisioning, change procedure
See Access Management procedure.Segregation of duties
Conflicting duties and areas of responsibility are segregated to reduce opportunities for unauthorized or unintentional misuse of Neuroscale assets. The initiation of an event is separated from its authorization. The possibility of collusion is considered when determining access levels.User responsibility for secret authentication information
Control and management of individual user passwords is the responsibility of all Neuroscale personnel and third-party users. Protect secret authentication information per the Information Security Policy.Password policy
Where feasible, passwords for confidential systems are configured to:- Be at least twelve (12) characters (eight (8) minimum where a system cannot be configured higher), including a mix of character classes.
- Lock out after 6 failed attempts.
- Require identity verification for any manual password reset.
- Not use secret questions (place of birth, etc.) as the sole password-reset requirement.
- Require the current password in addition to the new password during password change.
- Be stored in a hashed and salted format using a memory-hard or CPU-hard one-way hash function.
- Enforce appropriate account lockout and brute-force protection on account access.
System and application access
Information access restrictions
Applications must restrict access to authorized users in accordance with this policy. Restrictions are based on individual application requirements identified by the data owner. The application-specific access-control policy must conform to Neuroscale data-management requirements. Before implementation, evaluate application software against criteria including:- Sensitivity and classification of data.
- Risk of unauthorized access or disclosure.
- Granularity of access controls.
- Restrictions on data outputs.
- Controls between this and other applications.
- Programmatic restrictions on user access to functions and privileged instructions.
- Logging and auditing.
- Data retention and aging features.
Secure log-on
Secure log-on controls are designed and selected based on data sensitivity and unauthorized-access risk.Password management
Password-management systems are interactive and assist personnel in maintaining password standards. Storage and transmission of passwords use cryptographic protections (hashing or encryption).Privileged utility programs
Use of system utilities or other software capable of overriding system controls is restricted to the minimum personnel required. Use of utilities is logged. Extraneous utilities are removed or disabled during system build. Management approval is required prior to installing any ad hoc or third-party system utilities.Source code
Access to program source code, designs, specifications, and verification/validation plans is strictly controlled to prevent introduction of unauthorized functionality, avoid unintentional changes, and protect Neuroscale IP. All access is based on business need and logged for audit.Exceptions
Requests for exceptions must be submitted to the CISO for approval.Violations & enforcement
Report known violations to the CISO. Violations can result in suspension of system and network privileges and disciplinary action up to and including termination.Appendix A — Access management procedure
See Access Management procedure.Appendix B — Access matrix
The current access matrix (which roles have access to which systems) lives at the Standard Access Matrix.Version history
| Version | Date | Description | Author | Approved by |
|---|---|---|---|---|
| 1.0 | May 8, 2026 | Initial version | Cameron Wolfe | Ishan Jadhwani |