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 SharePoint (Engineering site).

​

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.

​

Segregation of duties

Conflicting duties and areas of responsibility are segregated, where the size of the organization permits, to reduce the risk of unauthorized or unintentional modification or misuse of Neuroscale’s systems and data:

• The engineer who authors a production change is not the sole approver of that change. Production deployments require an approving peer review on the pull request, and substantial changes additionally require system-owner or CTO authorization (see Change Management).
• Privileged actions are attributable to an individual and are logged independently of the person who performs them (see Administrator & operator logs).
• Where team size makes full separation of a duty impractical, the CISO documents the residual conflict and relies on compensating controls — independent logging, alerting, and after-the-fact review of the activity — rather than leaving the conflict unmanaged.

​

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. Production information-processing facilities are configured with redundancy sufficient to meet availability requirements; the cross-region and cross-zone replication and backup arrangements that support this are described under Information backup.

​

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.

​

Threat intelligence

Neuroscale collects and uses information about information-security threats to inform vulnerability management, risk assessment, and detection engineering (ISO/IEC 27001:2022 Annex A.5.7):

• Sources. The CISO maintains a set of threat-intelligence inputs: CISA advisories and the KEV (Known Exploited Vulnerabilities) catalog; vendor and product security advisories (PSIRTs) for in-use technologies (AWS, Cloudflare, HashiCorp, Rippling, GitHub, and others on the Vendor Inventory); the dependency-and-CVE feeds surfaced by the scanners in Vulnerability Management; and reputable industry threat reporting.
• Levels. Strategic (trends that inform the annual risk assessment), tactical (attacker techniques that inform detection and hardening), and operational (specific indicators and actively-exploited CVEs that drive immediate patching).
• Use. Relevant intelligence is triaged by the CISO and routed to: the technical vulnerability-management process for prioritized remediation (KEV-listed or actively-exploited findings are expedited); web filtering and malware controls (indicator blocking); the Annual Risk Assessment (strategic inputs); and the Incident Response Plan where an active threat warrants it.
• Cadence. Reviewed continuously as advisories arrive and summarized at each ISMS Management Review.

​

Contact with special interest groups

Neuroscale maintains contact with the wider security community so that it receives early warning of emerging threats, can share and learn defensive practice, and has an established channel to peers during an incident (ISO/IEC 27001:2022 Annex A.5.6):

• Membership. The CISO maintains active membership in at least one recognized security special-interest group or professional association — currently an OWASP North America chapter — and engages with its advisories and community channels.
• Subscriptions. The CISO subscribes to security advisory feeds and distribution lists, including CISA advisories and the KEV catalog, alongside the other threat-intelligence inputs above.
• Use. Information and contacts obtained through these groups feed the Threat intelligence process and the Incident Response Plan. Membership and subscriptions are confirmed for continued relevance at each ISMS Management Review.

This is distinct from contact with authorities and law-enforcement liaison, which sits with the CISO and General Counsel under the Incident Response Plan.

​

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. The flat prohibition and the narrow time-bounded exception (CTO and CISO written approval, scoped to a named workload and ≤30 days, with the approved scope, scrubbing approach, and end date recorded in an exception log retained as evidence) are defined in the Data Management Policy → Confidential data. Where this policy and the Data Management Policy appear to differ, the Data Management Policy controls.

​

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. Company email is protected by Microsoft 365’s built-in anti-malware and anti-phishing filtering (Exchange Online Protection). 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 quarterly (per the backup-restore test below).
• 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.
• In addition to daily backups, the Tier-1 RPO commitments in the RTO/RPO Matrix are achieved through continuous WAL-based replication for AWS Aurora and Vultr Postgres, and Vault Raft replication across regions for the secrets-of-record cluster. The daily backup is the recovery floor; the streaming-replication layer is the mechanism by which the 15-minute Tier-1 RPO is met.
• A quarterly backup-restore test (per data store) validates restorability and RPO conformance for each in-scope store; an annual full DR exercise (tabletop or live) validates the end-to-end recovery procedure. Both cadences operate per the DR & Backup-Restore Test procedure.

​

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 & boundary protection

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. Neuroscale does not operate a dedicated intrusion-detection/prevention (IDS/IPS) appliance. Boundary protection is provided by AWS VPC security groups and Cloudflare (single outbound-only ingress, WAF, and Zero Trust Access), with detection achieved through the logging, alerting, and file-integrity controls described above.

​

Control of operational software

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

​

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). Independence. Penetration tests are conducted by qualified third-party testers independent of Neuroscale’s engineering and security functions. The engagement is governed by a written scope letter signed by the CISO before testing begins (see Audit & pen-test access). Internal “red-team” exercises run by Neuroscale staff are supplemental and do not satisfy the annual independent-testing requirement. Retest of findings. Every Critical or High finding from a third-party penetration test is retested within 30 days of the engineering team’s reported remediation by the original tester (or another independent tester, where the original is unavailable). Retest closure evidence — a written confirmation from the tester that the finding is no longer reproducible, with screenshots or proof artifacts where applicable — is attached to the Vulnerability Register entry before the finding is marked closed. Medium and Low findings are retested at the next scheduled engagement unless customer contract or regulatory requirement obligates earlier retest. 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. Security-issue tickets (the security-tagged P0–P3 issues in the task tracker, monitored by Vanta) follow these same remediation SLAs, mapped by priority: P0 = 7 days (Critical), P1 = 30 days (High), P2 = 60 days (Medium), P3+ = 90 days (Low). See the Vulnerability Management standard. 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.
• Ceiling on duration. No risk acceptance for a Critical or High finding may extend beyond 2× the standard SLA (i.e., a maximum of 14 days for Critical, 60 days for High) without explicit CEO approval recorded in the ticket and reported at the next ISMS Management Review. Acceptances that hit the ceiling without CEO sign-off default to closure.
• 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