Key Management, Backup & Data Residency Policy

Use this page to understand how Nodinite separates cryptographic key handling, customer-controlled backup operations, and regional data residency requirements. It helps security reviewers, SQL Server administrators, and infrastructure teams document who owns key rotation, backup encryption, restore testing, and media destruction in a Nodinite deployment.

Understanding the Control Boundary

Before you define a backup policy or answer a compliance questionnaire, establish the trust boundary. Nodinite runs entirely on customer-controlled infrastructure, consumes approved keys and secrets from customer-managed stores, and does not create vendor-side copies of business data, backups, or physical media.

Diagram: Control flow for keys, databases, backups, and media destruction. The customer security team defines storage, access, and regional policy, while Nodinite services use approved keys without creating vendor-side data copies.

Components in Scope

Responsibility Model

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)

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 Nodinite 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-controlled cloud infrastructure, 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

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 and restoration operations; full database access is 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

Vendor 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 and 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 is provided by Nodinite. Certificates come from the cloud provider or the customer's IT team

DoD 5220.22-M Physical Destruction Standard

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

Compliance Path

1. Document all physical assets containing Nodinite data (databases, backups, logs, configurations).
2. Engage a certified IT asset recycling company (for example e-Stewards, R2 certified, or ISO 27001 certified).
3. Request destruction per DoD 5220.22-M or NIST SP 800-88.
4. Obtain a signed destruction certificate that lists asset models and serial numbers, the destruction method, the destruction date, and the certifying technician's name and credentials.
5. Retain the 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

Customers Deploying in a Cloud Subscription

• 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 the customer's cloud account manager)
• No destruction certificate comes from Nodinite. The certificate comes from the cloud provider or the customer's IT team

Next Step

• TLS Hardening

Related Topics

• TLS Hardening – Configure HTTPS/TLS for Nodinite v7
• HTTP Security Headers – HSTS, CSP, Permissions-Policy, Cache-Control IIS configuration
• Access Controls & Vendor Policy – Vendor zero-access architecture, application authentication, network recommendations
• Secret Management
• SQL Server Backup & Recovery
• Logging Service - Data Management
• Post Installation Steps