- 9 minutes to read

Key Management, Backup & Data Residency Policy

This page documents Nodinite's approach to cryptographic key management, backup encryption and residency, and physical media destruction — covering the customer's responsibilities and Nodinite's architectural guarantees.

Key Management Policy

Do you follow industry best practices for key management and ensure a secure key management policy throughout its lifecycle? — Yes. Nodinite key management follows NIST SP 800-57 recommendations for cryptographic key lifecycle, including secure generation, protected storage, rotation, and retirement.

Key Lifecycle Phases (NIST SP 800-57 Aligned)

Phase Description Nodinite Implementation
Generation Create cryptographic keys using validated algorithms Keys generated using .NET cryptographic libraries (approved by FIPS 140-2 where applicable)
Distribution Securely transmit keys to authorized entities Keys distributed only to local services via secure IIS app.config or Azure Key Vault. Not transmitted over network
Storage Protect keys at rest from unauthorized access SQL TDE keys stored in SQL Server key store; application secrets in Secret Management or Azure Key Vault; service account credentials in Windows Credential Manager or gMSA
Use Restrict key use to intended purpose and authorized entities Keys accessed only by authenticated services with role-based access. Audit logs record key use operations
Rotation Update keys to limit exposure from compromise TDE key rotation managed by customer's SQL Server admin; application secrets rotated per Secret Management policy
Retirement Securely destroy keys at end of lifecycle Keys retired when no longer needed; cryptographic erasure using NIST SP 800-88 methods; SQL backups containing retired keys are archived per retention policy

Storage & Protection

  • SQL TDE Encryption – Database encryption keys stored in SQL Server's secure key store, protected from filesystem access
  • Application Secrets – Connection strings, service account credentials, API keys stored in Secret Management with restricted file permissions (ACLs limit access to service accounts only)
  • Azure Key Vault (Optional) – If deployed in Azure, secrets can be stored in customer's Key Vault with automatic rotation and audit logging
  • Windows Credential Manager – Service account credentials stored with Windows DPAPI encryption when using gMSA

Rotation & Retirement Policy

  • TDE Key Rotation – Managed by customer's SQL DBA. See SQL Server TDE Documentation
  • Service Account Password Rotation – Monthly rotation recommended. Use Active Directory password policy or manual change if gMSA not available
  • Retired Key Destruction – Keys removed from active configuration after rotation. No recovery possible—crypto-erasure only method used
  • Retention & Archiving – Retired keys not archived; only current keys remain in active storage

Audit & Compliance

  • Key Access Logging – All key retrieval and cryptographic operations are logged in audit trails
  • Compliance Reports – SQL Server audit trails and [Logging Service audit logs][] provide evidence of key management compliance
  • NIST Alignment – Implementations follow NIST SP 800-57 Part 1 (General Guidance) and Part 3 (Application-Specific Guidance)

See Secret Management for detailed configuration and rotation procedures.

Backup & Data Residency Policy

Customer Responsibility: Backup strategy, encryption, storage location, and regional compliance are controlled entirely by the customer's infrastructure and policies. Nodinite stores data only on customer-controlled infrastructure; the customer has complete control over backup practices.

Data Subject to Backup Systems

Is customer data subject to backup systems? — Yes. All data stored in Nodinite Log Databases and Configuration Database should be included in the customer's backup strategy. Backup decisions are the customer's responsibility:

  • What gets backed up — Customer's SQL DBA decides which databases, transaction logs, and filegroups to include in backup plan
  • Backup frequency — Daily, hourly, or continuous backup determined by customer's RTO (Recovery Time Objective) and RPO (Recovery Point Objective) requirements
  • Backup retention — Customer determines how long backups are retained; Nodinite enforces data retention policy on active databases separately
  • Backup tools — SQL Server native backups, commercial backup software (Veeam, NetBackup, etc.), or cloud provider backup services (Azure Backup, AWS Backup)

Backup Encryption & Storage

Do you encrypt all backup data using AES-256 encryption and store backups securely (offsite/hardened)? — Yes, at customer's discretion.

Backup encryption and secure storage are customer-controlled and implemented via:

  • SQL Server backup encryption – Native SQL Server backup encryption using AES-256, configured per backup job 
    BACKUP DATABASE [NodiniteLogDatabase]
TO DISK = 'Z:\\Backups\\NodiniteLogDatabase.bak'
WITH ENCRYPTION (ALGORITHM = AES_256, SERVER CERTIFICATE = [BackupCertificate]);
  • Filesystem-level encryption – BitLocker (Windows), LUKS (Linux), or equivalent encryption on backup storage volumes
  • Cloud provider encryption – Azure Backup uses AES-256; AWS Backup uses KMS; GCP Backup uses Cloud KMS. All enabled by default
  • Offsite storage – Customer deploys backups to:
    • On-premise offsite NAS or tape library (isolated network segment)
    • Cloud backup service (Azure Backup, AWS Backup, AWS S3 with versioning)
    • Hybrid: Primary on-premise, secondary cloud redundancy

Backup Restoration Testing

Do you regularly test backup restoration procedures? — Customer responsibility. Nodinite recommends the following backup testing cadence:

  • Monthly – Full database restore test from oldest backup (tests oldest backup integrity)
  • Monthly – Restore to alternate SQL Server instance (validates portability)
  • Quarterly – End-to-end recovery test simulating production failover
  • Document RTO/RPO – Record actual restore time and data loss window; compare against SLA targets

See SQL Server Backup & Recovery documentation for testing procedures.

Data Residency & Regional Compliance

Do backups occur outside the EU, or do vendor employees have access from outside the EU? — No. Backup location and access are entirely customer-controlled:

  • Backup location — Customer specifies where backups are stored; backups remain in the region/location specified by customer
    • EU customers: Store backups within EU data centers only (on-premise, Azure EU, AWS EU regions)
    • US customers: Store backups in US data centers only
    • Other regional requirements: Customer enforces via backup policy and infrastructure
  • Backup access control — Only customer's authorized personnel can access backups. Nodinite has no access to backups
    • Backups protected by customer's AD permissions, RBAC, and network isolation
    • Offsite backups stored in customer-managed cloud accounts (customer's Azure subscription, customer's AWS account)
    • No vendor employee has credentials to access backup storage locations

Data Locality Guarantee

Will any data leave the origin creation (e.g., EU, US, or another regional solution including backups)? — No. Nodinite enforces data locality:

  • Data never leaves origin region – All Nodinite components (Web Client, Web API, Log API, Logging Service, SQL Databases, Log Databases) run on customer infrastructure in the specified region only
  • Database storage – SQL Server and Log Databases stored on customer-owned or customer-controlled cloud infrastructure in the specified region
  • Backups remain in region – Backups stored per customer's backup policy, which specifies regional location
  • No data replication – Data is never replicated to Nodinite cloud, parent company cloud, or any external service
  • No regional transcoding – Nodinite does not copy, sync, or migrate data across regions without explicit customer action

Regional Compliance Checklist:

Requirement Nodinite Responsibility Customer Responsibility
GDPR (EU) N/A — no vendor processing Ensure SQL Server in EU, backups in EU, no cross-border transfers
Data sovereignty N/A — no vendor storage Maintain infrastructure in specified country/region
Compliance audit Provide documentation confirming no vendor access Audit backup location and encryption status
Data portability Support export via Log API Maintain copies of backups for recovery testing

For GDPR-specific guidance, see Logging Service - Data Management.

Backup & Recovery Access Control

Do you enforce that access to backup and recovery systems is strictly limited to those with valid permissions? — Yes (Customer Controlled). Access to backup systems is restricted via:

  • Role-based access control (RBAC) — SQL Server backup jobs and backup storage access controlled by Windows Active Directory groups and backup software permissions
  • Network isolation — Backup storage (NAS, tape library, cloud accounts) restricted to authorized SQL DBA/backup admin accounts only
  • Cloud provider IAM — If using Azure Backup, AWS Backup, or GCP Backup, access controlled via customer's Azure RBAC, AWS IAM, or GCP IAM policies
  • Audit logging — SQL Server tracks backup operations in backup job logs and SQL audit logs; cloud backup services log access events via CloudTrail (AWS), Activity Log (Azure), or Cloud Audit Logs (GCP)
  • Principle of least privilege — Backup operators receive only permissions needed for backup/restore operations; full database access not required

Nodinite provides no backup system access—all access control is customer-owned and enforced by the customer's infrastructure and security team.

Media & Asset Destruction Policy

Nodinite Responsibility: None — Nodinite has no physical assets containing customer data.
Customer Responsibility: All physical media containing customer data must be destroyed per applicable standards.

Media Sanitization & Destruction Certification

Do you provide a certification of media sanitization/destruction? — No (Nodinite); Yes (Customer must obtain). Nodinite does not control physical media destruction because data is stored exclusively on customer-owned infrastructure. The customer's IT/facilities team is responsible for destruction certification:

  • On-premise infrastructure — Customer must destroy or certify destruction of:
    • Hard drives from SQL Server hosts
    • Backup media (tape drives, USB drives, NAS devices)
    • Network switches, routers, or security appliances that cached data
    • Old servers decommissioned after upgrades
  • Cloud infrastructure — If deploying in Azure/AWS/GCP:
    • Customer controls which data centers house infrastructure
    • Cloud provider destroys customer data per their destruction policy after deletion (see cloud provider SLAs)
    • No destruction certificate provided by Nodinite—only by cloud provider or customer's IT team

DoD 5220.22-M Physical Destruction Standard

For all physical assets that contain any DNV data, is the data/system destruction certified to minimum DoD standard 5220.22-M? — Customer responsibility. Nodinite recommends the following:

Physical Asset Destruction Standard Recommended Certificate
Hard drives (HDD) DoD 5220.22-M or NIST SP 800-88 Certificate of Destruction from certified IT recycler
Solid State Drives (SSD) NIST SP 800-88 (crypto-erase via ATA Secure Erase) Manufacturer/recycler destruction certificate
Backup tapes NIST SP 800-88 or manufacturer degaussing Tape destruction certificate from certified facility
Network equipment NIST SP 800-88 certified data wipe E-waste recycler certificate
Old servers Physical destruction (shredding) or certified data wiping + destruction Recycler destruction certificate

Compliance Path:

  1. Document all physical assets containing Nodinite data (databases, backups, logs, configurations)
  2. Engage certified IT asset recycling company (e.g., e-Stewards, R2 certified, ISO 27001 certified)
  3. Request destruction per DoD 5220.22-M or NIST SP 800-88 standard
  4. Obtain signed destruction certificate listing:
    • Asset models and serial numbers
    • Destruction method (e.g., "Multi-pass DoD 5220.22-M wipe" or "Secure erase + physical shredding")
    • Date of destruction
    • Certifying technician name and credentials
  5. Retain destruction certificate for audit trail and compliance evidence

Vendor Responsibility Scope

Nodinite provides no destruction services or certifications because:

  • Nodinite does not own or control physical infrastructure
  • No Nodinite employee has access to customer hardware
  • No Nodinite cloud infrastructure stores customer data (only customer infrastructure stores data)
  • Customer infrastructure is customer's responsibility to manage, control, destroy

For customers deploying Nodinite in a cloud subscription (Azure, AWS, GCP):

  • Customer determines where data is physically located (region, data center)
  • Cloud provider destroys customer data per their SLA after final deletion
  • Cloud provider can provide destruction certification upon request (contact customer's cloud account manager)
  • No destruction certificate from Nodinite—only from cloud provider or customer's IT team

Next Steps

TLS Hardening