heygrc
Answer

How do I add audit logging the right way for SOC 2 and ISO 27001?

Log the security-relevant events (who did what, and when), always include the actor, write them somewhere durable, and do not let a later cleanup delete them. SOC 2 (CC7.2) and ISO 27001 (A.8.15) both expect this, and both check it by sampling the events you actually recorded.

  1. Log the events that matter, with the actor

    Record the security-relevant actions: authentication, privilege and role changes, access to sensitive data, configuration changes. Each record needs enough to answer who did this, to what, and when, so always capture the actor, not just the action.

  2. Put the log somewhere it survives

    Write to a durable, tamper-resistant store, not only to stdout that rotates away, and tie the write to the change it records (the same transaction, or an outbox) so the event is not silently lost if the log call fails. The log is the evidence the control operated; if it is gone, so is the evidence an auditor samples and the trail you need after an incident.

  3. Protect it from the cleanup

    The most common way audit logging breaks is a later pull request deleting a log line that reads as noise. If a log is noisy, change its level or its destination, do not remove it. That is exactly the kind of change a review against A.8.15 should catch.

access/roles.ts+1 -0
async function updateRole(actor, target, role) {  await db.roles.set(target, role)+  await audit.log("role.update", { actor, target, role })  return ok()}
heygrcISO 27001 A.8.15 / SOC 2 CC7.2

The added line records who changed whose role. That is the event an auditor samples, and the one you want after an incident.