Operations Security Policy

​

Purpose

To ensure the correct and secure operation of information-processing systems and facilities.

​

Scope

All Neuroscale information systems that are business-critical and/or process, store, or transmit company data. Applies to all Neuroscale employees and other third-party entities with access to Neuroscale networks and system resources.

​

Documented operating procedures

Both technical and administrative operating procedures are documented as needed and made available to all users who need them. Engineering runbooks live in Notion.

​

Change management

See Change Management for the engineering procedure. Changes to the organization, business processes, information-processing facilities, production software and infrastructure, and systems that affect information security are tested, reviewed, and approved prior to production deployment.

​

Documentation and review

• All significant changes to systems, networks, and processing facilities are documented.
• Documentation includes purpose, specification, potential impact considering dependencies, and deployment plan.
• Changes are tested and reviewed in environments segregated from both production and development (staging).

​

Approval and authorization

• Changes with substantial impact on information security and operational functionality must obtain formal authorization before deployment.
• Emergency changes may be expedited but undergo retrospective review and authorization.

​

Procedures

• Planning and impact assessment — evaluate potential impacts considering system dependencies.
• Authorization — secure necessary approvals before initiating changes.
• Communication — inform internal and external stakeholders about planned changes, schedules, and expected impact in advance.
• Testing and quality control — changes are tested thoroughly and meet quality standards.
• Implementation — changes are executed per the planned deployment schedule.
• Emergency management & remediation — failed changes are reverted.

​

Emergency changes

An emergency change is a change that must bypass the normal lead time to remediate an active production incident, security risk, or regulatory deadline.

• Emergency changes require contemporaneous written approval (Slack or ticket comment is acceptable) from the on-call Engineering Lead and, for changes affecting production access or data, the CISO.
• The emergency change is captured in the standard ticket / PR record at the time of execution; the ticket is flagged emergency-change.
• A retrospective review is performed within 5 business days by the Engineering Lead and the CISO: scope, justification, what was changed, what risk was carried, and any follow-up. The retrospective is filed in the ticket and copied into the SharePoint evidence library for SOC 2 / ISO 27001 review.
• Repeat emergency-change patterns are reviewed quarterly by the CISO for control-design weaknesses.
• Documentation — ticketing systems and code repository keep records of changes, commits, and deployments.

​

Continuity and consistency

• ICT continuity plans, response, and recovery procedures are kept consistent with changes.
• Operating documentation and user procedures are maintained.

​

Security and integrity

Changes preserve the confidentiality, integrity, and availability of information.

​

Capacity management

Use of processing resources and storage is monitored and adjusted to ensure availability and performance meet requirements. Human-resource skills, availability, and capacity are reviewed as a component of capacity planning and as part of the annual risk assessment. Scaling resources for additional capacity, without changes to the system, can be done outside the standard change-management and code-deployment process.

​

Data leakage prevention

To minimize the risk of leaking sensitive information:

• Identify and classify information per the Data Management Policy.
• Provide awareness training including appropriate use and handling of sensitive information.
• Use technical monitoring and DLP tools where warranted by risk.

​

Web filtering

The organization ensures safe, secure, and appropriate internet use:

• Use mechanisms such as secure DNS and IP/domain blocking to restrict access to high-risk websites — Cloudflare One (Gateway DNS/HTTP filtering plus WARP-tunneled egress) and Rippling (endpoint).
• Browser and anti-malware technologies block known malicious websites.
• Block sites with: known malicious content, command-and-control servers, malicious threat intelligence, illegal-content sharing.

​

Separation of environments

Development and staging environments are strictly segregated from production to reduce the risk of unauthorized access or changes. Confidential production customer data must not be used in development or test environments. If production data is exceptionally approved by the CTO for development or testing, it is scrubbed of any sensitive information whenever feasible.

​

Configuration & hardening

Systems and networks are provisioned and maintained per the standards in Configuration & Hardening. Firewalls and appropriate network access controls are used to control traffic to and from production. Production network-access configuration rules are reviewed at least annually.

​

Protection from malware

Anti-malware protections are deployed on all company-issued endpoints (except OSes not normally prone to malware) — Rippling. Threat detection and response is also enabled for company email — Material. Anti-malware software detects common malware threats and performs mitigation (remove, block, quarantine). All files are scanned on introduction and on access/modification/download. Definitions and engine updates are configured to install automatically. Known or suspected malware incidents are reported as security incidents. It is a violation of company policy to disable or alter anti-malware configuration without authorization.

​

Information backup

Backup procedures are designed and implemented to maintain and recover customer data per documented SLAs. Security measures protect backups per the confidentiality of the data.

• Backup copies of information, software, and system images are taken regularly.
• Backups are tested at least annually.
• Backups are stored in a region or availability zone separate from the production data location — configured cross-region in AWS, and across distinct Vultr regions for Vultr-hosted workloads. Where contractually required, Vultr-hosted Confidential data also maintains a cross-cloud backup copy in AWS S3 with Object Lock.
• Neuroscale does not regularly back up user devices (laptops). Critical files belong in the company-sanctioned file storage repository.
• Backups run daily on in-scope systems. Schedules are maintained within the backup application.
• An annual backup-restore test validates the data and process.

​

Logging & monitoring

Production infrastructure produces detailed logs appropriate to function. Event logs of user activities, exceptions, faults, and security events are produced and reviewed manually or via automation. Alerts are configured for events representing significant threats to confidentiality, availability, or integrity. Logging requirements for production applications and supporting infrastructure:

• User log-in and log-out.
• CRUD (create, read, update, delete) operations on application/system users and objects.
• Security-settings changes (including disabling/modifying logging).
• Application owner / administrator access to customer data (Access Transparency).
• Logs include user ID, IP address, valid timestamp, action type, and action object.
• Logs do not contain sensitive data or payloads.

​

Log retention tiers

Log retention is tiered by the type of event. Where a customer contract, regulatory regime, or active legal hold requires longer retention, that requirement governs. Hot retention is the period during which logs are searchable through the standard query interface (Better Stack, CloudWatch Logs Insights). Cold retention is the period during which logs are archived to S3 (with object lock where appropriate) and remain restorable for incident, audit, or legal-hold purposes. Retention floors above are minima — operational systems may retain longer where useful and where storage and privacy considerations permit. 13 months is selected to support: (a) SOC 2 Type II audit windows (typically 12 months, with grace); (b) retrospective determination of when the controller became aware of a breach for GDPR Art. 33 / state-AG breach analyses — the 72-hour notification clock runs from awareness, and “awareness” is sometimes only definable after multi-week investigation; and (c) typical attacker-dwell-time distributions (industry medians are measured in months, occasionally longer). See Logging & Monitoring for engineering specifics.

​

Protection of log information

Logging facilities and log information are protected against tampering and unauthorized access.

​

Administrator & operator logs

System administrator and operator activities are logged and reviewed/alerted per system classification and criticality.

​

Data restore logs

Restoring production data containing PII from backups, for service or testing purposes, is logged or tracked in auditable tickets.

​

Clock synchronization

Clocks of all relevant information-processing systems are synchronized to network time servers using reputable time sources.

​

File integrity monitoring & intrusion detection

Production systems monitor, log, and self-repair / alert on suspicious changes to critical system files where feasible. Alerts are configured for suspicious conditions and engineers review logs regularly. Unauthorized intrusions and access attempts or changes are investigated and remediated per the Incident Response Policy.

​

Control of operational software

Installation of software on production systems follows the change-management requirements above.

​

Threat intelligence

Information relating to information-security threats is collected and analyzed:

• Collect from blogs, news articles, vendor updates, public databases, and industry communities.
• Analyze for actionable insights; report specific threats to the Security team.
• Disseminate via Slack, email, and emergency alerts.
• Feedback drives continuous improvement and policy review.

​

Technical vulnerability management

See Vulnerability Management. Vulnerability scans are performed on public-facing production systems at least quarterly. Penetration tests of applications and the production network are performed at least annually (and after major changes). Vulnerabilities are evaluated by Engineering and Security; risk-relevant critical or high vulnerabilities create a service ticket. Severity may differ from automatically generated ratings based on Neuroscale’s understanding of architecture and exploitability. Tickets for vulnerabilities not remediated within the standard timeline must show a risk-treatment plan and planned remediation timeline.

​

Risk acceptance for vulnerabilities

Where a vulnerability cannot be remediated within the standard timeline (compensating control in place, vendor patch unavailable, business-impact constraint), a documented risk acceptance is required:

• Owner submits the acceptance via the vulnerability ticket with: scope, severity, compensating controls, residual risk, business justification, target review date.
• Approver: CISO (and, for any acceptance with material customer or regulatory exposure, the CEO).
• Review cadence: every accepted exception is reviewed at least quarterly; expired acceptances default to closure unless re-approved.
• All accepted exceptions are listed in the Vanta risk register and reviewed during the SOC 2 / ISO 27001 audit cycles.

​

Restrictions on software installation

Rules governing user installation of software are established per the Information Security Policy.

​

Information systems audit considerations

Audit requirements and activities involving verification of operational systems are carefully planned and agreed to minimize disruption to business processes. To protect the confidentiality, integrity, and availability of production during audit testing (ISO 27001 Annex A.8.34):

• Read-only by default. Auditors and pen-testers operate under read-only credentials unless write access is explicitly required and pre-approved.
• Planned windows. Active testing is performed in pre-agreed windows; impact to availability is assessed in advance and the engineering on-call is notified.
• Change-freeze coordination. Production change-freezes coordinated with the audit cadence prevent confounding test results.
• Log integrity. Audit access is logged; logs are protected per the Protection of log information §above, and auditor activity is retained alongside other production logs.
• Scope agreement. Audit and pen-test scope is documented in a written engagement letter (or, for internal audit, a CISO-approved scope memo) before testing begins.
• Sensitive data. Auditors handling Confidential data are bound by NDA and the Third-Party Management Policy due-diligence tier appropriate to the data.

​

Systems security assessment & requirements

Risks are considered prior to acquisition of, or significant changes to, systems, technologies, or facilities. Where requirements are formally identified, relevant security requirements are included. Acquisition of new suppliers and services is per the Third-Party Management Policy. The company performs an annual network-security assessment including review of major changes such as new system components and network topology.

​

Data masking

Data masking is implemented based on risk or specific requirement:

• Adopt techniques such as data masking, pseudonymization, or anonymization to protect PII and sensitive data.
• Pseudonymization and anonymization break the link between PII and individuals.
• Consider all elements of information for adequate anonymization.
• Methods may include encryption, character nulling/deleting, varying numbers and dates, substitution, or hashing.
• Queries and masks disclose only the minimally required data.
• Mechanisms for data obfuscation consider the specific circumstances under which data should be concealed.

​

Exceptions

Requests for exceptions must be submitted to the CISO for approval.

​

Violations & enforcement

Report violations to the CISO. Violations may result in suspension of privileges and disciplinary action up to and including termination.

​

Version history