Compliance

OBSESC runs in your AWS account and stores data in resources you own, so you stay the controller and custodian of your log data. This page describes the features you can use to meet retention, legal-hold, data-protection and access-accountability requirements. Whether a given configuration satisfies a particular regulation is for you and your auditor to decide.

Data residency

Everything OBSESC stores stays in the AWS account and Region where you deploy it:

• OBSESC’s working data is on EBS volumes attached to your node.
• The original events are in your S3 bucket, in open formats. The bucket can be in another Region (S3Region), but then every write and read crosses Regions.
• Your log content is never sent to the vendor. See Security model for the outbound calls the node makes.

Retention

A global window

storage.retention_window_days sets how many days of history to keep. If you leave it unset, data is kept indefinitely.

storage:
  retention_window_days: 400

Per-service windows and a compliance floor

You can give classes of service different windows, and set a floor that no window is allowed to go below:

retention:
  min_window_days: 30              # nothing may be shorter than this
  policies:
    - match: { service_glob: "payments-*" }
      retention_window_days: 2555  # 7 years
    - match: { service_glob: "debug-*" }
      retention_window_days: 30

• Matching: the most specific match wins. An exact service name beats a glob, and a glob with more literal characters beats a looser one. Services with no match use the global window.
• The floor is enforced at startup. A config that would delete data sooner than min_window_days won’t load.
• Raw events are kept for the longest window. Raw data in S3 holds events from many services together, so it is kept until the longest window has passed. To remove specific records sooner, use erasure.
• Matching is by service only. A policy that tries to match on an attribute is refused when the config loads.

The console shows your retention settings and any open legal holds.

If your raw bucket moves objects to Standard-IA or Glacier Instant Retrieval, deleting them before that storage class’s minimum storage duration incurs an early-deletion charge from AWS. The node checks your retention windows against this at startup and warns you. When the stack creates the bucket, it fills this in for you. If you brought your own bucket, declare its lifecycle rules so the warning is accurate:

storage:
  lifecycle:
    standard_ia_after_days: 30
    glacier_ir_after_days: 180

Legal holds

A legal hold stops retention from deleting data in a time range. Holds override every retention policy, and they also block erasure.

1. Open a hold by sending POST /v1/holds to your query API with a service glob, a time range and a reason. You need the hold:write permission (admin only by default). The person who opened the hold is recorded from your sign-in, not from the request.
2. Check open holds in the console, or with GET /v1/holds.
3. Close a hold with DELETE /v1/holds/<id> when the matter ends. This hands the range back to retention.

Raw data is held when it overlaps the hold’s time range, whatever its service.

Write-once storage (S3 Object Lock)

For WORM (write once, read many) requirements, the stack can create the raw bucket with S3 Object Lock enabled. You can only do this when the bucket is created. An existing bucket can’t be converted.

Parameter	Value
CreateRawBucket	true
EnableObjectLock	true
ObjectLockMode	governance (holders of s3:BypassGovernanceRetention can still delete) or compliance (nobody can delete, not even the root user)
ObjectLockRetainDays	Days each object version stays locked

• Every raw data object is written with a retain-until date.
• The node won’t start if the bucket doesn’t report Object Lock as enabled, so a misconfigured bucket can’t silently downgrade your protection.
• When you open a legal hold, you can ask for the lock on the covered objects to be extended.
• On a locked bucket, deletions by retention and by erasure create delete markers. Through OBSESC, the data is gone immediately. In S3, the locked versions remain until their retain-until date. Choose ObjectLockRetainDays to match your goal, and tell your auditor which goal you chose.

compliance mode can’t be reversed for the object versions it covers.

Right to erasure

Erasure removes specific records, for example everything relating to one user, from both your raw events and OBSESC’s own stored data. It is off by default, and it needs a setting turned on in advance. Contact us to enable erasure before you need it.

Once erasure is enabled, it takes two steps, and needs the erase:write permission (admin only by default):

1. Plan. Describe what to remove: at least one of a service, an attribute and value, or text in the event body, plus a time range. Give a reason and the name of the person or team responsible. The plan shows what would be removed and any legal holds that block it. Planning doesn’t change anything.
2. Execute. Confirm the same request. OBSESC removes the matching records.

• What you asked to erase isn’t stored, because it identifies the data subject. Only a digest is kept. The exception is when the audit trail is set to record query text, in which case the trail stores the full request.
• If custody verification is on, the erasure is recorded so later verification still passes.
• On an Object Lock bucket, the erased records are unreadable through OBSESC, but the locked versions remain in S3 until their retain-until date. OBSESC warns you when this applies.

Redaction at ingest

Often the simplest option is to mask personal data before it’s stored. Redaction rules run before anything is written, so redacted values are never stored anywhere:

ingest:
  redaction:
    - field: user.email          # replace the whole value of one attribute
      replacement: "[redacted]"
    - regex: '\b\d{16}\b'        # replace matches in the body and every attribute value
      replacement: "****"

Each rule sets exactly one of field or regex. If a regex doesn’t compile, the node won’t start.

Access accountability

Requirement	OBSESC feature
Record who accessed log data	Query audit trail, on by default
Show that OBSESC’s stored records haven’t been altered	Optional custody verification
Protect raw events from deletion or change	S3 Object Lock on the raw bucket
Give a third party evidence it can check	Evidence bundles
Limit access by role	RBAC and single sign-on
Encrypt data at rest and in transit	Encryption

The audit trail is designed to support access-logging controls in frameworks such as SOC 2, ISO 27001, PCI DSS and HIPAA. Your auditor decides whether your configuration meets them.

Checking your configuration

The node checks your configuration when it starts. It refuses to start if a retention window is below your floor, a redaction rule is invalid, or the bucket doesn’t have the Object Lock setting you asked for. It warns you if a retention window conflicts with your declared lifecycle. If you’d like a configuration reviewed before you apply it, contact us.