Skip to content
Melina Security

Security & Data Handling

Melina Security handles client systems and data with controls proportional to the sensitivity of the engagement. This page documents our standing...

By Tatiana K.

Melina Security handles client systems and data with controls proportional to the sensitivity of the engagement. This page documents our standing security controls, our data-handling practices during engagements, and the retention policies that apply after engagement close.

This is a summary. The engagement-specific data-handling addendum in each Statement of Work may impose stricter controls than what’s documented here; in that case the SOW controls govern.

1. Engagement infrastructure

Melina operates a dedicated engagement infrastructure separate from corporate IT. Engagement-related work uses:

  • Dedicated workstations or hardened virtual machines for sensitive engagements (per-engagement isolation; no co-mingling of client data across engagements)
  • Encrypted disk volumes on all engagement systems (full-disk encryption with managed key custody)
  • Multi-factor authentication on all systems and services
  • VPN-gated network access to engagement infrastructure from the public internet
  • Logging and monitoring of access to engagement data with retention per §6
  • Separation of concerns: the engagement team has access only to their engagement’s data; cross-engagement access requires documented justification

2. Client data classification

We classify data received from or discovered about clients during engagements into three tiers:

  • Tier A — high sensitivity: personal data, credentials, internal source code, trade secrets, regulator-relevant documents, evidence of breaches by third parties
  • Tier B — engagement-sensitive: scope documents, threat models, finding reports prior to delivery, intermediate artifacts (firmware extracts, packet captures), redacted screenshots
  • Tier C — engagement-related but non-sensitive: generally-published documents, vendor security advisories, public threat-intel correlated with the engagement

Tier A receives the strictest handling: encrypted at rest, encrypted in transit, access logged at the row level where technically feasible, retained only for the minimum duration required.

3. Data in transit

  • All client communication occurs over TLS 1.3 (or TLS 1.2 where 1.3 is not supported by the client’s infrastructure)
  • Document exchange uses end-to-end-encrypted channels (encrypted email with PGP for high-sensitivity, or a managed encrypted document platform)
  • Live testing traffic to client systems uses VPN where the client provides one, or TLS-only with mutual authentication for direct testing
  • We do not transmit Tier A data over unencrypted channels; we do not transmit any tier over consumer messaging platforms (SMS, unencrypted IM)

4. Data at rest

  • Tier A: encrypted at rest with per-engagement encryption keys; key access is logged; retention limited per §6
  • Tier B: encrypted at rest with engagement-scoped keys; access limited to engagement team
  • Tier C: standard encryption; access limited to those who need to know

Backups are encrypted with managed keys; backup retention follows §6. We do not store client data in unmanaged cloud locations (personal Dropbox, GitHub gists, etc.) — only on managed Melina infrastructure with documented controls.

5. Personnel access

Engagement team members access client data only as required to perform engagement work. Access is provisioned at engagement start and de-provisioned at engagement close. Specific controls:

  • Background check: Melina engagement personnel undergo background verification consistent with their access level
  • Confidentiality agreements: all engagement personnel sign confidentiality agreements that survive employment
  • Need-to-know basis: team members access only their assigned engagements; cross-engagement access requires documented justification
  • Training: all engagement personnel receive recurring training on data handling, restricted-language compliance, responsible disclosure, and applicable regulatory frameworks (GDPR, PIPL, CCPA as relevant to the engagement)

6. Retention

Default retention:

  • Engagement artifacts (reports, captured evidence, working files): 90 days after engagement close, then destroyed
  • Final deliverables (signed reports, formal certifications): retained per client agreement, typically 1-3 years
  • Engagement metadata (dates, scope summary, billing): retained for audit and tax compliance per applicable law (typically 5-7 years)
  • Personal data discovered during testing: retained only as long as required for the active engagement; destroyed at engagement close unless the client explicitly requests otherwise

Clients may request shorter retention than the default; we accommodate when operationally possible. Clients may request longer retention; we accommodate when contractually agreed and operationally possible.

Destruction: at the retention deadline, client data is securely deleted (cryptographic erasure for encrypted storage; multi-pass overwrite for physical media when applicable). A destruction certificate is provided on request.

7. Data location and jurisdiction

Melina Security (Shenzhen) Co., Ltd. is registered in Shenzhen, China (Qianhai WFOE). Default engagement infrastructure is hosted in mainland China and Hong Kong, with regional infrastructure (depending on engagement requirements) in:

Clients with specific data-residency or jurisdiction requirements (e.g., GDPR data subject in EU, PIPL Cross-Border restrictions) are accommodated through region-specific engagement infrastructure or alternative arrangements documented in the SOW.

For mainland China engagements, ICP-filed Melina assets and managed Chinese cloud infrastructure (Aliyun / Tencent Cloud) are used per regulatory requirement.

8. Subprocessors

Melina uses a small number of subprocessors for engagement-supporting services (cloud hosting, encrypted document workspace, secure email). The current subprocessor list is available on request and is referenced in engagement-specific SOWs. We notify clients of material changes to the subprocessor list in advance per the SOW.

9. Incident response

If Melina experiences a security incident affecting client data:

  • Affected clients are notified within the period required by applicable law (typically within 72 hours of confirmation for personal data breaches under PIPL / GDPR)
  • An incident report is provided to affected clients describing the incident, the data affected, remediation steps, and recommended actions
  • We support affected clients with regulatory notification processes as requested
  • A post-incident review is conducted; structural changes are made where indicated

10. Compliance frameworks

Melina aligns its security and data-handling controls with:

  • ISO 27001 (in progress / planned per Trust > Compliance & Certifications — P1.5)
  • SOC 2 Type 2 (planned per same)
  • PIPL (China; binding for Melina as a Shenzhen entity)
  • GDPR (EU; binding for engagements with EU data subjects)

Specific evidence of compliance — certificates, audit reports — is available under NDA on request.

11. Contact

For questions about Melina’s security or data-handling practices, including specific control evidence under NDA: