Security, Compliance, and Certifications

Why Security Documentation Matters in eDiscovery

Discovery data is, by definition, sensitive. It includes privileged communications, confidential business records, personal data about employees and customers, health information, and financial records. A vendor that cannot answer specific security questions during procurement is a liability, not a resource. NYCF publishes this page to answer those questions directly and allow legal, IT, privacy, and security teams to evaluate NYCF's posture against their own requirements before a matter begins.

Buyers should not accept vague claims about "enterprise-grade security" from any discovery provider. The questions that matter are specific: which certifications have been independently audited? How is encryption implemented? Who can access client data, and under what conditions? How is a chain-of-custody record generated and maintained? What happens if there is a security incident? This page answers those questions with the specificity that procurement teams, outside counsel security questionnaires, and DFS-regulated clients require.

Certifications and Standards

NYCF's eDiscovery platform and operations are built around independently audited security frameworks. The certifications listed here reflect formal third-party assessments, not self-declarations.

SOC 2 Type II: NYCF's platform undergoes annual SOC 2 Type II audits covering the Trust Services Criteria (security, availability, processing integrity, confidentiality, and privacy). Type II audits evaluate the operating effectiveness of controls over a defined period, not just point-in-time design. The resulting report documents that NYCF's access controls, change management, incident response, and data handling procedures functioned as designed throughout the audit period. Reports are available under NDA to qualified clients during procurement due diligence.

ISO/IEC 27001: NYCF's information security management system is certified against ISO/IEC 27001, the international standard for systematic management of information security risks. Certification requires establishing a documented ISMS, implementing controls across 114 domains including access control, cryptography, physical security, and supplier management, and passing an independent certification audit with annual surveillance reviews.

ISO/IEC 27017 and 27018: NYCF's cloud operations align with ISO/IEC 27017, which extends 27001 with controls specific to cloud service environments, addressing shared responsibility boundaries, virtual machine protection, and cloud-specific access management. For matters involving personal data, NYCF follows ISO/IEC 27018, the code of practice for protection of personally identifiable information in public cloud environments, which is directly relevant to GDPR and NY SHIELD Act compliance questions about cloud-hosted eDiscovery data.

HIPAA: NYCF operates under a Business Associate Agreement framework for matters involving protected health information. HIPAA-covered matters are hosted in a HIPAA-compliant environment with appropriate administrative, physical, and technical safeguards, audit logging, and breach notification procedures aligned with the HIPAA Breach Notification Rule. This is particularly relevant for New York healthcare providers and life sciences companies with litigation matters involving patient data.

FedRAMP: For federal government clients and matters involving federal data, NYCF supports FedRAMP-aligned hosting configurations. Clients with specific FedRAMP Moderate or High requirements should contact NYCF's security team directly to discuss hosting architecture applicable to their matter.

New York Regulatory Framework

New York companies face a regulatory environment for data handling that goes beyond federal baselines. NYCF's eDiscovery operations are designed with those requirements in mind.

NY SHIELD Act: The Stop Hacks and Improve Electronic Data Security Act expanded New York's data breach notification obligations and imposed reasonable data security requirements on any person or business that owns or licenses computerized data including private information of a New York resident. "Private information" under the SHIELD Act includes Social Security numbers, driver's license numbers, financial account information, biometric information, usernames and passwords, and health information. eDiscovery collection routinely touches all of these categories. NYCF's collection workflows are configured to handle SHIELD Act-covered private information with the same access controls, encryption, and audit logging that the Act's "reasonable security" standard requires. Data transfers are documented, access is logged, and private information is not retained beyond the matter's agreed retention period.

DFS Cybersecurity Regulation (23 NYCRR 500): Financial services companies regulated by the New York Department of Financial Services are subject to 23 NYCRR 500, which requires a documented cybersecurity program, access controls, multi-factor authentication, encryption of nonpublic information in transit and at rest, audit trails, incident response planning, and third-party service provider oversight. When a DFS-regulated company engages NYCF for eDiscovery, NYCF operates as a covered service provider under Section 500.11. NYCF's controls are designed to satisfy DFS's third-party requirements: MFA is enforced for all platform access, nonpublic information is encrypted at rest using AES-256 and in transit using TLS 1.2 or higher, immutable audit logs are maintained for all access events, and NYCF can provide the representations required for DFS third-party due diligence reviews.

New York Attorney General and Enforcement Context: The New York Attorney General's office has been active in enforcing data security obligations under state law, including the SHIELD Act, and has prosecuted cases where companies failed to implement adequate data security for sensitive information. NYCF's documentation practices are designed to support the type of records that demonstrate reasonable security measures if NYCF's handling of client data is ever reviewed in an enforcement context.

Security Architecture

Access Controls

NYCF enforces role-based access controls across all platform functions. Review platform access is provisioned by matter: a user on one matter cannot access another. Administrative access to infrastructure is restricted to named personnel with a business need, and all administrative actions are logged in an immutable audit trail. Multi-factor authentication is required for all platform access, including administrative functions. Privileged access reviews are conducted quarterly, and access is revoked immediately upon personnel change or matter close.

Encryption at Rest and in Transit

All client data stored on NYCF's Advantage Plus platform is encrypted at rest using AES-256. Data in transit between client systems and NYCF's platform is encrypted using TLS 1.2 or higher, with TLS 1.3 preferred for all new connections. Encryption keys are managed through a dedicated key management service with annual rotation and access logging. NYCF does not store encryption keys in the same environment as the encrypted data. These controls satisfy both the DFS 23 NYCRR 500 encryption requirements and the SHIELD Act's reasonable security standard for private information.

Logging and Auditability

Every action on NYCF's platform generates an audit log entry: who accessed a document, what action was taken, and when. Log entries are written to an append-only store that cannot be modified by platform users, including administrators. Logs are retained for a minimum of seven years. On request, NYCF can provide a complete audit log for any matter, showing every access event from ingestion through production. That log supports chain-of-custody documentation, DFS audit requirements, and any security incident response that requires reconstruction of access patterns.

Chain of Custody

Chain of custody in eDiscovery means being able to answer, at any point in time, where a piece of data came from, who handled it, what was done to it, and where it went. NYCF's methodology generates this record automatically at every stage of the workflow.

At collection, NYCF generates a forensic log that records the source system authenticated, the tool and version used, the date and time of collection, the personnel who executed the collection, and the cryptographic hash (SHA-256) of each collected item. That hash is re-verified at ingestion into the processing environment. If any file fails hash verification, the collection is flagged and the source file is re-collected before processing continues.

Through processing, deduplication, and culling, every transformation applied to the data set is documented with the parameters used and the volume of items affected. The processing log links back to the collection log through a matter-level chain-of-custody record. Review actions, including coding, privilege designations, and redactions, are recorded in the audit log but are kept separate from the forensic chain-of-custody record to preserve the integrity of the collection documentation independent of review decisions.

At production, NYCF generates a production manifest listing every produced document, its Bates identifier, its original collection source, the processing parameters applied, any redactions applied, and the hash of the produced file. That manifest is delivered alongside the production and supports a complete reconciliation from produced document back to original source data. For SDNY and EDNY matters where production completeness is challenged before a magistrate judge, that manifest is the starting point for any reconciliation.

Incident Response and Data Residency

NYCF maintains a documented incident response plan that is tested annually through tabletop exercises. In the event of a confirmed or suspected security incident affecting client matter data, NYCF notifies affected clients within 72 hours of confirmation, consistent with GDPR Article 33 timelines, HIPAA Breach Notification Rule requirements, and NY SHIELD Act breach notification obligations. The notification includes the nature of the incident, the data types and approximate volumes affected, the steps NYCF has taken to contain and remediate, and NYCF's contact for ongoing communication.

Data residency is configurable for matters with specific geographic requirements. By default, NYCF processes and stores matter data in United States-based infrastructure. Clients with EU data residency requirements, UK jurisdiction restrictions, or other cross-border transfer constraints should specify those requirements at matter intake. NYCF does not transfer matter data to third-party subprocessors outside the agreed data residency region without explicit client authorization.

Audit Procedures and Third-Party Assessments

NYCF's information security program is subject to annual third-party audits for SOC 2 Type II and ISO 27001 surveillance. Audit reports are available to qualified clients under NDA upon request. NYCF also supports client-directed security questionnaires and procurement due diligence reviews, including the third-party vendor due diligence questionnaires that DFS-regulated institutions are required to conduct under 23 NYCRR 500.11. Clients requiring site visits or architecture review sessions for high-sensitivity matters should request those through NYCF's account management team.

Privacy-Aware Discovery

Personal data collected in the course of eDiscovery is subject to the same privacy obligations that apply to any other processing of that data. NYCF's privacy-aware discovery framework addresses this directly.

NY SHIELD Act: NYCF's collection workflows flag private information as defined by the SHIELD Act: Social Security numbers, driver's license numbers, financial account numbers, biometric information, usernames and passwords, and health information. That flagging enables counsel to make informed decisions about whether personal data outside the matter's scope should be excluded before it is processed, and it supports the documentation that demonstrates reasonable safeguards if the handling of private information is later scrutinized.

GDPR: For matters involving EU personal data, NYCF operates as a data processor under Article 28, with a written Data Processing Agreement that specifies the categories of data processed, the legal basis for processing, the security measures in place, the data retention and deletion schedule, and the subprocessor chain. Cross-border transfers from the EU to the United States are conducted under Standard Contractual Clauses as adopted by the European Commission.

CCPA: NYCF acts as a service provider under the California Consumer Privacy Act for matters involving California residents' personal information. NYCF does not sell, share, or use personal information collected in the course of an engagement for any purpose other than the specific eDiscovery services requested. Clients may request a CCPA-compliant service provider agreement as part of the engagement documentation.

Cross-Border Transfer Restrictions: Some jurisdictions impose restrictions on transferring personal data for litigation purposes. NYCF's collection workflows can be configured to collect and process data within a specified jurisdiction, to flag cross-border transfers for privacy counsel review before they occur, and to document the legal basis for any approved transfer. NYCF does not assume that litigation necessity provides an automatic override of applicable transfer restrictions, and treats cross-border transfers as requiring explicit scoping decisions at the outset of each matter.

AI Governance

NYCF uses AI-assisted tools for predictive coding, near-duplicate grouping, email threading, and early case analytics. Each of these tools is used as an aid to human reviewers and project managers, not as a substitute for human judgment. NYCF's AI governance framework reflects three principles that courts, the Sedona Conference, and leading practitioners have emphasized: explainability, human oversight, and documented validation.

On explainability, NYCF's AI tools provide a rationale for each prioritization or relevance prediction at the document level. Reviewers can see why a document was surfaced as likely relevant, which features drove the prediction, and how the model was trained. That transparency allows reviewers to calibrate their reliance on the tool and identify cases where the model's predictions should be overridden.

On human oversight, no document is coded as responsive or non-responsive, produced, or withheld based solely on an AI prediction. Every AI-assisted review queue is reviewed by a human attorney or qualified reviewer. Documents coded as non-responsive by an AI-assisted workflow are subject to quality-control sampling before the review set is finalized. The QC rate and methodology are documented and available for disclosure if the review process is challenged in SDNY, EDNY, or any other forum.

On validation, NYCF documents the training set used to build any predictive coding model, the metrics used to evaluate model quality (precision, recall, F1 scores), and the validation protocol applied before the model was used for production-level coding. That documentation follows the guidance in the Sedona Conference TAR Case Law Primer and supports an elusion-testing or random-sample-based validation response if opposing counsel requests an explanation of the review methodology.

How NYCF Handles Your Matter Security

Biometric Litigation Support

Biometric litigation has become one of the most technically demanding areas of eDiscovery. Illinois's Biometric Information Privacy Act (BIPA) has generated more class action litigation than any other state privacy law, and its influence has reached New York courts through cases involving Illinois-based employees or multistate operations. The FTC's biometric policy statement has expanded regulatory scrutiny across facial recognition, voice biometrics, fingerprints, iris scans, and derived data including templates and embeddings. NYCF has developed a specific collection and analysis framework for matters involving biometric data.

Biometric eDiscovery covers more than documents. The relevant evidence in a BIPA case or FTC enforcement action typically includes written retention and destruction policies, notice documents provided to individuals, consent records, vendor contracts governing biometric data collection or processing, templates and embeddings stored by the system (often in proprietary formats), audit logs showing who was enrolled and when, access logs showing which personnel accessed biometric data, training and testing datasets used to develop biometric models, and records documenting deletion of biometric data. NYCF's collection workflow addresses all of these source types, not only conventional documents and email.

For BIPA-specific matters, NYCF's collection protocol targets the systems that generate and store the relevant evidence: employee onboarding systems, time and attendance platforms, access control systems, third-party biometric vendor APIs, and the internal policy and consent management repositories. NYCF's forensic analysis documents what the data shows about the company's collection and storage practices; the legal team uses that analysis to assess compliance and exposure.

The FTC has defined biometric information broadly to include any data derived from face, voice, fingerprints, iris or retina, genetics, and other physical characteristics, including templates, embeddings, and other derived representations. NYCF's collection scope for FTC-adjacent matters extends to AI model training datasets, embedding stores, and any system that processes biometric-derived data, not only systems that capture biometric data at enrollment. This broader scope avoids the collection gaps that create problems when regulators ask why certain evidence was not preserved. New York employers that use biometric technology for timekeeping, access control, or security screening should consult counsel about their BIPA exposure before litigation arises, and NYCF can assist with the preservation planning that reduces risk at that stage.