Access Control Policy

​

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 non-public data — i.e., data classified as Confidential or Restricted under the Data Management Policy. Restricted is the default classification for internal Neuroscale content (internal policies, meeting minutes, internal reports), so this scope reaches all internal collaboration and engineering systems (Slack, Microsoft 365, GitHub, Linear, Vanta) in addition to production infrastructure that holds Confidential customer data. 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. Multi-Factor Authentication (MFA) is required for every Neuroscale-managed account that accesses a company system, regardless of privilege level. This includes the Microsoft 365 tenant (mail, SharePoint, Teams), Slack, GitHub, Linear, Vanta, Better Stack, and any other SaaS reached through the Rippling identity provider. Rippling enforces MFA enrollment as a precondition for SSO; users who have not completed enrollment cannot authenticate to downstream applications. In addition to the universal MFA baseline, privileged access to production infrastructure (AWS Identity Center, Vultr, KMS / secrets-manager consoles, production databases, root cloud accounts) requires MFA with a phishing-resistant factor (WebAuthn / FIDO2 hardware key or platform authenticator). SMS and email-based factors are not acceptable for privileged access.

​

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 created Access 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. The removal SLA is tiered by the nature of the separation: Highly privileged credentials (production-data access, root cloud accounts, MFA-enrollment authority) are rotated immediately on separation regardless of the cause; SSO session revocation precedes credential rotation.

​

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.

Where SSO is supported, Rippling is the source of truth and these requirements are enforced upstream.

​

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.

All unnecessary default accounts must be removed or disabled before a system is networked. Vendor default passwords and credentials must be changed before deployment.

​

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.

​

Cross-references

• Access Management procedure — provisioning, deprovisioning, and change procedure.
• Standard Access Matrix — the current access matrix (which roles have access to which systems).

​

Version history