Legacy data migration plan for re-encryption

CWE-311 applies to legacy data as much as to new records: financial systems that added encryption requirements mid-lifecycle often have years of plaintext records in production tables that were never backfilled. PCI-DSS 4.0 Req-3.4 requires that stored PANs be unreadable anywhere they are stored — legacy records are not exempt. NIST SC-28 requires confidentiality of information at rest regardless of when it was written. A re-encryption plan with 0% progress means the encryption controls that apply to new records do not protect the existing dataset, which is typically the most valuable target for attackers exfiltrating historical financial data. Without a tracked migration plan, legacy exposure compounds with every passing month.

Audit existing tables for unencrypted sensitive columns, then build an incremental re-encryption migration with rollback capability:

// scripts/re-encrypt-legacy.ts
import { db } from '../src/lib/db';
import { encryptField } from '../src/lib/encryption';

const BATCH_SIZE = 1000;

async function reEncryptAccounts() {
  let offset = 0;
  let processed = 0;

  while (true) {
    const rows = await db.query(
      `SELECT id, account_number FROM accounts
       WHERE encrypted_at IS NULL LIMIT $1 OFFSET $2`,
      [BATCH_SIZE, offset]
    );
    if (rows.length === 0) break;

    for (const row of rows) {
      const encrypted = await encryptField(row.account_number);
      await db.query(
        'UPDATE accounts SET account_number = $1, encrypted_at = NOW() WHERE id = $2',
        [encrypted, row.id]
      );
    }
    processed += rows.length;
    console.log(`Re-encrypted ${processed} records`);
    offset += BATCH_SIZE;
  }
}

Document progress in docs/legacy-migration.md with phase dates and record counts. Keep unencrypted backups in isolated storage with restricted access until migration is complete and verified — do not delete them until re-encryption integrity is confirmed.