Audit & lifecycle: audit logs, data retention, xóa theo yêu cầu, continuity/backups

1. Tại sao bạn cần audit & lifecycle trong ChatGPT App

Khi bạn còn viết nguyên mẫu, người dùng là chính bạn, DB là SQLite cục bộ, và “sự cố” được chữa bằng git reset --hard, mọi thứ trông có vẻ đơn giản, “ấm cúng”.

Nhưng ngay khi GiftGenius (hoặc App ChatGPT khác) có người dùng thật, đặc biệt có thanh toán và PII, thì bỗng nhiên xuất hiện:

• bộ phận an ninh của khách hàng hỏi “ai có thể xem đơn hàng của chúng tôi và ai đã thay đổi chúng?”;
• luật sư hỏi “bạn lưu dữ liệu bao lâu và thực hiện yêu cầu ‘hãy xóa tôi’ như thế nào?”;
• thực tế production hỏi “điều gì sẽ xảy ra nếu dev drop bảng ở prod?”

Trong bài này, ta sẽ đi qua bốn khối trụ:

1. Audit‑logs — lớp ghi log riêng cho bảo mật và kiểm toán.
2. Data retention — thời hạn sống của từng loại dữ liệu và cách triển khai.
3. Xóa theo yêu cầu người dùng — “quyền được lãng quên” dưới góc độ kỹ thuật.
4. Business continuity & backups — cách vượt qua sự cố mà không mất dữ liệu và uy tín.

Các ví dụ sẽ gắn với App học tập của chúng ta (GiftGenius trên Next.js + Apps SDK + MCP) khi có thể.

2. Audit‑logs: ai, làm gì, khi nào và kết quả ra sao

Audit‑logs khác gì với logs thông thường

Application‑logs thông thường là các thông điệp thân thiện cho developer. Ở đó có các stack trace, thông tin debug, giá trị biến kỳ lạ, và những console.log("chắc chắn ở đây không nên là null"). Chúng sống không lâu và chủ yếu dành cho kỹ sư đọc.

Audit‑logs là một thế giới khác. Khán giả chính — đội an ninh, kiểm toán, đôi khi là luật sư. Họ không cần dòng “NullPointer ở dòng 55”, họ cần bản ghi kiểu “người dùng X thay đổi cài đặt thanh toán của tổ chức Y vào lúc nào đó, kết quả — thành công”. Audit‑records thường sống lâu hơn nhiều (nhiều năm) và được xem là bằng chứng trong điều tra.

Khác biệt chính:

OWASP và các hướng dẫn tương tự nhấn mạnh: audit‑logs nên để ở kho hoặc bảng riêng, không trộn với logs ứng dụng thông thường.

Nên log gì trong ngữ cảnh ChatGPT‑App

Với ChatGPT‑App, nhất là có thương mại, mức tối thiểu hợp lý cho audit là:

• sự kiện xác thực: đăng nhập, đăng xuất, nỗ lực đăng nhập;
• thao tác với dữ liệu nhạy cảm: tạo/cập nhật/xóa hồ sơ, đơn hàng, cài đặt thanh toán;
• hành động quản trị: đổi vai trò, thay đổi cài đặt tenant;
• gọi các công cụ nhạy cảm của MCP/Agents: create_order, charge_customer, cancel_subscription v.v.

Trực giác tốt: mọi thứ mà khi có sự cố bạn sẽ hỏi theo kiểu “ai đã làm và thông qua cái gì?” — thì nên đưa vào audit.

Cấu trúc sự kiện audit

Mô hình tinh gọn: mỗi bản ghi là “ai / hành động gì / lên cái gì / trong bối cảnh nào / với kết quả gì”. Thường được mô tả bằng cấu trúc who, action, resource, context, outcome.

Cho GiftGenius của chúng ta, mô tả interface bằng TypeScript:

// lib/audit.ts
export type AuditAction =
  | "auth.login"
  | "auth.logout"
  | "order.create"
  | "order.cancel"
  | "account.delete"
  | "giftidea.generate";

export interface AuditEvent {
  eventId: string;          // uuid
  timestamp: string;        // ISO
  actor: {
    userId: string | null;  // có thể null trước khi đăng nhập
    tenantId?: string | null;
    ip?: string | null;
    client: "chatgpt-app" | "admin-panel" | string;
  };
  action: AuditAction;
  resource?: {
    type: string;           // "order", "user", ...
    id?: string;
  };
  context?: {
    mcpTool?: string;
    requestId?: string;
  };
  outcome: {
    status: "success" | "failure";
    reason?: string | null;
  };
}

Lưu ý, trong sự kiện không có đầy đủ e‑mail, số thẻ và các PII khác mà trước đây ta đã học cách che/mask và không log khi không cần thiết.

Lưu trữ audit‑logs ở đâu và như thế nào

Yêu cầu tối thiểu cho kho lưu trữ:

• bảng riêng hoặc thậm chí DB riêng so với logs thông thường để khó vô tình ghi đè;
• nên ở chế độ append‑only: về mặt kỹ thuật có thể chỉ là chính sách “không bao giờ UPDATE/DELETE bảng này”, thêm một role DB chỉ có quyền INSERT và SELECT;
• quyền truy cập hạn chế: không phải toàn bộ đội kỹ sư đều được quyền đọc toàn bộ audit.

Nếu bạn dùng PostgreSQL qua Prisma/Drizzle, mô hình có thể như sau (đơn giản hóa):

CREATE TABLE audit_events (
  event_id   uuid PRIMARY KEY,
  created_at timestamptz NOT NULL DEFAULT now(),
  actor_user_id text,
  actor_tenant_id text,
  actor_ip      inet,
  action        text NOT NULL,
  resource_type text,
  resource_id   text,
  context_mcp_tool text,
  context_request_id text,
  outcome_status text NOT NULL,
  outcome_reason text
);

Sơ đồ có thể tùy biến theo nhu cầu, nhưng điều quan trọng là tính có cấu trúc. JSON rác gộp một dòng sẽ khiến bạn khổ sở về sau.

Triển khai audit trong App của chúng ta

Tạo một helper nhỏ trong ứng dụng Next.js (môi trường Node, ví dụ trong MCP‑server hoặc API‑route):

// lib/audit.ts
import { randomUUID } from "crypto";
import { db } from "./db"; // client đến CSDL của bạn

export async function logAudit(event: Omit<AuditEvent, "eventId" | "timestamp">) {
  const full: AuditEvent = {
    ...event,
    eventId: randomUUID(),
    timestamp: new Date().toISOString(),
  };

  // Trong thực tế — qua hàng đợi/nền, ở đây chỉ chèn trực tiếp
  await db.insertInto("audit_events").values({
    event_id: full.eventId,
    created_at: full.timestamp,
    actor_user_id: full.actor.userId,
    action: full.action,
    outcome_status: full.outcome.status,
    outcome_reason: full.outcome.reason ?? null,
    // ...các trường khác
  });
}

Bây giờ thêm lời gọi vào handler tạo đơn hàng (giả sử đây là MCP‑tool hoặc endpoint phía server):

// app/api/orders/route.ts
export async function POST(req: Request) {
  const user = await requireUser(req); // từ mô-đun xác thực
  const body = await req.json();
  const order = await createOrderInDb(user, body);

  await logAudit({
    actor: { userId: user.id, client: "chatgpt-app" },
    action: "order.create",
    resource: { type: "order", id: order.id },
    context: { mcpTool: "create_order_tool" },
    outcome: { status: "success" },
  });

  return Response.json(order);
}

Tương tự với các thao tác rủi ro — hủy đơn, đổi thông tin thanh toán, xóa tài khoản.

Ta đã có một lớp audit riêng biệt và có cấu trúc — rất tốt. Câu hỏi tự nhiên tiếp theo: bao lâu tất cả các sự kiện này (và dữ liệu người dùng khác) nên sống và xử lý thế nào khi hết hạn?

3. Data retention: dữ liệu của bạn sống bao lâu

Tại sao không thể lưu mọi thứ mãi mãi

Bản năng kỹ sư “biết đâu cần” trong bối cảnh dữ liệu người dùng — rất nguy hiểm.

Thứ nhất, càng giữ dữ liệu lâu và nhiều, hậu quả khi rò rỉ càng nặng: thùng xăng càng to, cháy càng khủng. Nhiều hướng dẫn bảo vệ dữ liệu gọi dữ liệu là “tài sản độc hại”: phải lưu trữ có mục đích, nhưng tối thiểu hóa dung lượng và thời hạn.

Thứ hai, pháp luật như GDPR/CCPA đưa ra nguyên tắc “không lâu hơn mức cần cho mục đích xử lý”. Tức là không thể giữ dữ liệu cá nhân vô thời hạn “để phòng”. Với mỗi loại dữ liệu phải có thời hạn lưu rõ ràng và thủ tục xóa hoặc ẩn danh hóa.

Thứ ba, lưu trữ đám mây tốn tiền. Các bảng log lớn và lịch sử chat phình rất nhanh, và sau một năm dễ nhận ra nửa hóa đơn hạ tầng là “rác của hôm qua”.

Dữ liệu khác nhau — thời hạn khác nhau

Kinh nghiệm doanh nghiệp và hướng dẫn công khai cho thấy bức tranh xấp xỉ sau:

Lưu ý: đây không phải tư vấn pháp lý, chỉ là định hướng kỹ thuật. Với sản phẩm thật, bạn cần thống nhất thời hạn với luật sư, nhưng về kỹ thuật bạn phải sẵn sàng triển khai các TTL khác nhau.

Triển khai retention trong code

Mô hình phổ biến: bảng có created_at hoặc expires_at, và có một tiến trình định kỳ xóa hoặc ẩn danh hóa bản ghi cũ.

Ví dụ: dọn logs thường, cũ hơn 90 ngày.

// scripts/cleanup-logs.ts
import { db } from "../lib/db";

async function cleanup() {
  await db
    .deleteFrom("app_logs")
    .where("created_at", "<", new Date(Date.now() - 90 * 24 * 60 * 60 * 1000));
  console.log("Old logs removed");
}

cleanup().catch(console.error);

Script này có thể chạy theo cron, qua GitHub Actions theo lịch, hoặc bằng scheduler của cloud.

Với PII, thay vì xóa thường sẽ ẩn danh hóa. Ví dụ, đơn hàng cũ hơn N năm bị gỡ liên kết khỏi người dùng cụ thể:

UPDATE orders
SET user_id = NULL
WHERE created_at < now() - interval '3 years';

Khi đó giữ lại số tiền, sản phẩm và các “khoản kế toán” khác, nhưng không còn liên kết đến cá nhân.

Đừng quên bản sao lưu cũng phải có thời hạn sống của riêng nó. Chu kỳ và thời gian lưu backup sẽ bàn ở phần backup, nhưng tư tưởng giống nhau: ngay cả archive cũng không thể giữ mãi, nếu không “quyền được lãng quên” chỉ còn trên giấy.

4. Xóa theo yêu cầu người dùng: “quyền được lãng quên” trong code

Nguồn gốc yêu cầu

GDPR của EU (và các luật tương tự) đưa ra “quyền được lãng quên”: người dùng có thể yêu cầu xóa dữ liệu cá nhân, và công ty phải làm điều đó không chậm trễ vô lý.

Với developer, điều này có nghĩa: sớm muộn bạn sẽ nhận được yêu cầu “hãy xóa mọi dữ liệu về tôi” (hoặc bạn tự làm nút “Delete my data”), và khi đó không chỉ xóa bản ghi trong bảng users, mà còn phải đi theo toàn bộ dấu vết: đơn hàng, phiên, token, nhật ký, CRM, thanh toán, v.v.

Tuy nhiên, cũng có những luật yêu cầu bạn phải lưu một số dữ liệu: ví dụ giao dịch tài chính. Vậy nên ở đây phức tạp pháp lý thường nhiều hơn kỹ thuật.

Cần dọn những gì

Tối thiểu cho GiftGenius của chúng ta:

• hồ sơ người dùng (tên, e‑mail, cài đặt);
• phiên, refresh‑token, liên kết với nhà cung cấp OAuth;
• đơn hàng, nếu không cần ở dạng “cá nhân hóa” (hoặc có thể ẩn danh hóa);
• logs và audit‑records có chứa PII (ví dụ e‑mail ở dạng thô).

Đồng thời giữ lại dữ liệu quan trọng cho báo cáo, nhưng đã ẩn danh — tổng tiền, số giao dịch, tổng hợp theo quốc gia, v.v.

Ví dụ thuật toán xóa

Kịch bản:

1. Người dùng (đã đăng nhập) bấm “Xóa tài khoản của tôi”.
2. Server nhận yêu cầu với userId của họ.
3. Server:
   • xóa/ẩn danh hóa bản ghi phụ thuộc (đơn hàng, phiên, tích hợp);
   • dọn PII trong hồ sơ;
   • ghi một bản ghi vào audit‑log “đã xử lý yêu cầu xóa dữ liệu”.

Để đơn giản, minh họa tối thiểu trên vài bảng. Trong sản phẩm thật bạn sẽ thêm các thực thể khác (tích hợp, dịch vụ bên thứ ba, v.v.) quanh lõi này.

Mã dịch vụ trong Next.js (ví dụ đơn giản):

// app/api/delete-me/route.ts
import { db } from "@/lib/db";
import { logAudit } from "@/lib/audit";

export async function POST(req: Request) {
  const user = await requireUser(req);

  await db.transaction(async (tx) => {
    await tx.deleteFrom("sessions").where("user_id", "=", user.id);
    await tx.deleteFrom("orders").where("user_id", "=", user.id);

    await tx.updateTable("users")
      .set({
        is_deleted: true,
        name: null,
        email: null,
      })
      .where("id", "=", user.id);

    await logAudit({
      actor: { userId: user.id, client: "chatgpt-app" },
      action: "account.delete",
      outcome: { status: "success" },
    });
  });

  return new Response(null, { status: 204 });
}

Trong thực tế bạn sẽ thêm các lời gọi API ngoài (ví dụ Stripe — để gỡ liên kết customer), và giao dịch sẽ “nặng đô” hơn. Nhưng nguyên tắc cốt lõi đã rõ: gom ở một nơi, có ghi audit.

Mối liên hệ với backup

Phần “backup” chứa nhiều câu hỏi thú vị. Dù bạn đã xóa người dùng khỏi DB chạy thật, dữ liệu của họ có thể còn trong snapshot đêm qua. Để tránh biến thành “thực tế chẳng bao giờ xóa ai”, có hai hướng:

1. Backup có thời hạn riêng (ví dụ 30–90 ngày), hết hạn thì biến mất cùng dữ liệu. Sau khi hết retention, cả DB chính lẫn archive đều không còn người dùng đó.
2. Nếu bạn phải khôi phục từ backup, hãy có sổ “ID đã xóa”, và sau khi phục hồi, chạy lại script xóa/ẩn danh hóa.

Ở công ty lớn đôi khi dùng crypto‑shredding: PII của người dùng được mã hóa bằng khóa riêng, và khi có yêu cầu xóa thì hủy khóa. Dù bản sao dữ liệu mã hóa có nằm đâu đó (trong logs, backup), không có khóa cũng là rác vô dụng. Rất hay, nhưng hơi “khoa học tên lửa” cho startup.

Điểm UX quan trọng

Hãy nhớ, xóa không chỉ là SQL. Người dùng kỳ vọng:

• cách gửi yêu cầu rõ ràng (nút, form, e‑mail);
• thời hạn xử lý hợp lý (thực tế thường đến 30 ngày);
• thông báo thành công hoặc lý do từ chối (ví dụ khi một phần dữ liệu buộc phải lưu theo luật).

Về kỹ thuật, bạn đã sẵn sàng: biết dọn dẹp, ghi log hành động và không lưu thừa trong backup.

5. Business continuity & sao lưu

Hãy tưởng tượng mọi thứ ở trên hoạt động hoàn hảo… cho đến khi xảy ra DROP TABLE orders, sự cố cloud hoặc rớt cả region. Ta cần cơ chế để đưa dịch vụ trở lại trong thời gian hợp lý và không mất dữ liệu quan trọng.

RTO và RPO — hai chữ cái định nghĩa “đau đớn” của bạn

Hai tham số cơ bản của Disaster Recovery:

• RTO (Recovery Time Objective) — thời gian bạn có thể chấp nhận bị gián đoạn. Ví dụ, nếu RTO = 1 giờ, nghĩa là sau sự cố nghiêm trọng, bạn phải khôi phục tối đa trong một giờ.
• RPO (Recovery Point Objective) — khoảng dữ liệu (theo thời gian) bạn chấp nhận mất. Nếu RPO = 10 phút, khi khôi phục có thể mất tối đa 10 phút dữ liệu gần nhất, nhưng không hơn.

Sản phẩm càng quan trọng (ngân hàng, giao dịch), hai tham số càng tiến về 0. Với GiftGenius học tập, có thể sống với RTO ~ vài giờ và RPO ~ 15–60 phút, nhưng vẫn cần hiện thực hóa.

Điều gì có thể xảy ra trong stack của bạn

Trong bối cảnh ChatGPT‑App trên Vercel + DB đám mây + API ngoài, danh sách sự cố phổ biến:

• OpenAI API không khả dụng: App trả lỗi cho các tool‑calls.
• Vercel (hoặc bên khác) gặp sự cố: widget không gọi tới backend của bạn được.
• Cơ sở dữ liệu bị hỏng hoặc xóa nhầm gì đó (ví dụ DROP TABLE).
• Tài khoản bị xâm nhập điều khiển hạ tầng.

Đối phó bằng tổ hợp backup, replication và hành vi ứng dụng hợp lý khi gặp sự cố.

Chiến lược sao lưu

Postgres/cloud DB hiện đại thường có tối thiểu ba lựa chọn:

1. Backup đầy đủ + tăng dần.
   Snapshot đầy đủ mỗi ngày và lưu thay đổi tăng dần giữa các snapshot. Khôi phục = quay về snapshot cụ thể + áp nhật ký thay đổi.
2. Point‑in‑Time Recovery (PITR).
   DB ghi nhật ký giao dịch (WAL) và cho phép khôi phục về thời điểm bất kỳ (ví dụ “tại 14:03:00, trước khi chúng ta drop bảng”).
3. Replication sang region khác.
   Giữ replica DB thụ động/hoạt động ở region/cloud khác. Khi mất region chính có thể chuyển App sang replica, chỉ mất phần dữ liệu chưa kịp đồng bộ.

Với quy mô của chúng ta, thường chỉ cần bật PITR ở nhà cung cấp DB và backup off‑site định kỳ.

Ví dụ đơn giản: dump hàng ngày cho DB local/dev

Dù production dùng DB quản lý, với staging/dev đôi khi bạn vẫn muốn có script đơn giản:

# scripts/backup.sh
#!/usr/bin/env bash
set -e
DATE=$(date +%F)
pg_dump "$DATABASE_URL" > "backups/backup-$DATE.sql"
echo "Backup created: backups/backup-$DATE.sql"

Có thể chạy bằng cron hoặc GitHub Actions. Quan trọng — backup cũng cần xóa theo thời hạn.

Hành vi App khi dịch vụ ngoài bị lỗi

Backup và PITR giải quyết bài toán “khi mọi thứ sập hoàn toàn hoặc dữ liệu hỏng”. Nhưng trong thực tế kinh doanh thường gặp sự cố một phần — API ngoài ngã, mạng đứt, cổng thanh toán treo.

Khi OpenAI API hoặc cổng thanh toán “nằm”, chiến lược tệ nhất là trả 500 kèm stack trace vô nghĩa. Lý tưởng là:

• backend trả lỗi có cấu trúc như { error: "upstream_unavailable" };
• widget hiện thông báo dễ hiểu: “Dịch vụ tạm thời không khả dụng, vui lòng thử lại sau”;
• hệ thống không spam API đang “nằm” bằng retry vô tận (các pattern như Circuit Breaker sẽ bàn kỹ trong module về độ bền vững).

Ví dụ handler MCP‑tool xử lý lỗi bên ngoài:

// mcp/tools/createGiftIdea.ts
export async function createGiftIdea(args: Input): Promise<Output> {
  try {
    return await callOpenAiModel(args);
  } catch (err) {
    await logAudit({
      actor: { userId: args.userId ?? null, client: "chatgpt-app" },
      action: "giftidea.generate",
      outcome: { status: "failure", reason: "openai_unavailable" },
    });
    throw new Error("UPSTREAM_UNAVAILABLE");
  }
}

Lớp trung gian giữa MCP và widget của bạn sẽ biết cách hiển thị lỗi này trong UI một cách gọn gàng.

Kiểm tra khôi phục: backup mà không restore — chỉ là một file

Mẫu phản‑pattern kinh điển: backup được tạo hàng ngày, ai cũng yên tâm… cho đến khi phát hiện không thể khôi phục (đổi format, mất khóa, thiếu dung lượng).

Kế hoạch tối thiểu:

• định kỳ (ví dụ mỗi tháng) dựng môi trường staging từ backup;
• chạy qua các kịch bản cơ bản: đăng nhập, tạo đơn hàng, App hoạt động;
• đảm bảo thời gian khôi phục và mất dữ liệu nằm trong RTO/RPO của bạn.

Thay vì một khóa học “tôn giáo DevOps”, trong phạm vi bài này chỉ cần hiểu: quy trình sao lưu là một phần của kiến trúc App, không phải “thứ gì đó ai đó trên cloud sẽ lo”.

6. Trực quan hóa: vòng đời dữ liệu và sự kiện

Để mọi thứ không chỉ là chữ, ta vẽ hai sơ đồ đơn giản.

Vòng đời dữ liệu người dùng

flowchart TD
  A["Tạo dữ liệu<br/>(đăng ký, đặt hàng)"] --> B["Lưu trữ và sử dụng<br/>(prod DB)"]
  B --> C["Lưu trữ/ghi tổng hợp<br/>(chỉ số ẩn danh)"]
  B --> D[Yêu cầu xóa]
  D --> E[Xóa/ẩn danh hóa<br/>trong prod DB]
  E --> F["Hết thời hạn lưu của bản sao lưu<br/>(retention)"]
    

Ý chính: vòng đời dữ liệu không kết thúc ở DB production — nó tiếp tục trong các bản sao lưu.

Dòng audit cho thao tác rủi ro

sequenceDiagram
  participant User as Người dùng
  participant ChatGPT as ChatGPT
  participant App as Backend/MCP của bạn
  participant DB as CSDL
  participant Audit as Audit storage

  User->>ChatGPT: "Hủy đơn hàng #123"
  ChatGPT->>App: callTool cancel_order
  App->>DB: UPDATE orders SET status='canceled'
  App->>Audit: INSERT audit_event {actor, action, resource, outcome}
  App-->>ChatGPT: Kết quả thao tác
  ChatGPT-->>User: Thông báo về kết quả
    

7. Lỗi điển hình trong audit & lifecycle

Lỗi số 1: Trộn audit‑logs và logs thông thường.
Khi mọi thông điệp rơi vào một logs‑index chung, sau nửa năm chẳng ai phân biệt được “người dùng đã đổi vai trò admin” với “lại null reference”. Audit phải có sự kiện có cấu trúc ở tầng business (xem phần cấu trúc sự kiện audit) và kho riêng với quyền truy cập hạn chế.

Lỗi số 2: Log PII trong audit và debug‑logs.
Đầy đủ e‑mail, điện thoại, địa chỉ giao hàng, bốn số cuối của thẻ — thường vô tình lọt vào log. Điều này tăng rủi ro rò rỉ và trái khuyến nghị về quyền riêng tư. Thay vào đó hãy log identifier và giá trị đã che/mask.

Lỗi số 3: Không có chính sách retention — “lưu mọi thứ mãi mãi”.
Ở giai đoạn MVP tưởng “không sao”, nhưng sau một năm bảng phình to quá mức, truy vấn analytics biến thành DDoS chính DB. Thêm nữa là vi phạm nguyên tắc tối thiểu hóa dữ liệu trong luật hiện đại. TTL tối thiểu cho từng loại dữ liệu phải được lên kế hoạch, và dọn dẹp phải tự động hóa.

Lỗi số 4: “Xóa theo yêu cầu” == DELETE FROM users.
Nếu bạn chỉ xóa dòng người dùng nhưng để lại PII của họ trong đơn hàng, phiên và log, thực chất bạn chưa xóa ai cả. Cách đúng là đi xuyên suốt các thực thể liên quan trong một giao dịch, nơi không thể xóa thì ẩn danh hóa. Và đừng quên ghi chính sự kiện xóa đó vào audit‑log.

Lỗi số 5: Bỏ qua backup khi xóa dữ liệu.
Xóa người dùng ở prod — tốt, nhưng dữ liệu của họ vẫn sống trong snapshot cũ một năm. Khi khôi phục từ đó, mọi thứ “tái sinh”, và bạn lại vi phạm cam kết với người dùng và trong Privacy Policy. Cần hoặc giới hạn thời hạn backup, hoặc có thủ tục áp lại các xóa sau khi khôi phục.

Lỗi số 6: “Chúng tôi đã bật backup, thế là ổn”, nhưng không ai từng thử khôi phục.
Backup chưa từng thử restore chỉ là một file đắt tiền. Không kiểm tra khôi phục định kỳ, bạn không biết RTO/RPO thực tế, cũng không biết DR‑plan của mình có hoạt động không. Tối thiểu — thường xuyên dựng staging từ backup theo checklist.

Lỗi số 7: Tài liệu và thực tế không khớp.
Trong Privacy Policy bạn viết lưu log 30 ngày và xóa dữ liệu theo yêu cầu, còn trong code thì giữ mãi. Cửa hàng ChatGPT, khách hàng enterprise và kiểm toán viên dễ phát hiện qua câu hỏi “cho xem bảng retention” và “hãy trình diễn xóa một người dùng cụ thể”. Tốt nhất là làm trước, rồi mới viết.