Enable application and API logging

These services are the front doors and engines of the company's applications. "Logging" on them is exactly what it sounds like: a record of what each request, query, build, transfer or workflow did. This cluster of findings flags services that are doing their job but keeping no durable record of it. None of the findings break anything or cost money directly; the cost is contingent and lands later, when an incident or an auditor asks what happened on a given day and the honest answer is "we were not recording."

Several frameworks the company likely cares about expect this. The audit-and-accountability family of NIST 800-53 and PCI DSS section 10 both require that activity on systems is logged and reviewable. A failing application-logging control is a concrete, citable gap that pulls down a compliance score and shows up in a SOC 2 or PCI review. The fix is almost entirely CloudWatch Logs or S3 storage, which is small and controllable with retention policies.

There is one genuine cost trap to manage. Verbose, full-payload logging on a high-traffic API or a high-volume workflow generates real CloudWatch volume, and full request bodies can capture sensitive data in the logs. The right ask is: turn logging on, default to the lighter level in production, cap retention, and redact sensitive fields. That clears the controls without trading a logging gap for a storage bill or a data-handling problem.

Dmitri brings the batch of application-logging findings to his finance partner because the report shows a cluster of red across API Gateway, Athena, DMS and Step Functions and he wants the spend sized before he turns anything on. The partner's starting point is reassuring on cost: the fix is almost entirely CloudWatch Logs or S3 storage, typically a few dollars to low tens of dollars a month per active service at a sensible level. As remediation goes, this is one of the cheapest groups on the board. None of the findings break anything or cost money today; the cost of the gap is contingent and lands later, mid-incident or mid-audit, when someone asks what happened on a given day and the honest answer is we were not recording.

The one trap the partner flags is verbose logging. Full-payload tracing on a high-traffic API or a high-volume workflow generates real CloudWatch volume, and full request bodies can capture credentials and PII straight into the log groups. So the finance ask is precise: turn logging on, default to the lighter level in production, cap retention on every destination, and redact sensitive fields. That clears the controls without trading a logging gap for a storage bill or a data-handling problem. The partner also notes that a reappearing finding count is a build-discipline signal worth tracking, since logging that is not baked into templates means the same gap-by-default pattern is probably true of other controls too.

The direct cost of fixing these controls is small: CloudWatch Logs or S3 storage, typically a few dollars to low tens of dollars a month per active service at a sensible logging level. As remediation goes, this is one of the cheapest groups on the board. The reason it matters is the cost of the audit gap it represents, not the cost of fixing it.

The controls map to the audit-and-accountability family of NIST 800-53 and to PCI DSS section 10, the parts of most frameworks that say you must be able to show what your systems did. A failing finding is a specific resource an auditor can point at, and for a company carrying a SOC 2, PCI or FedRAMP commitment that is exactly what erodes the score reported externally.

Watch the bill after any logging push. The lighter level is cheap; the verbose level and full request-body tracing on a busy service can add real money and capture sensitive data. The right ask is log on by default, lighter level in production, capped retention, redacted fields. And treat a reappearing finding count as a build-discipline signal: if new findings keep arriving every time a service ships, logging is not baked into the templates, and the same gap-by-default pattern is probably true of other controls.

Our applications run through managed services: API gateways, GraphQL APIs, query engines, build systems, data-movement pipelines and workflows. This group of findings means some of them are running with no durable record of what they did. Everything works day to day, until a customer or an auditor asks what happened on a given date and the honest answer is that we were not recording.

This is a low-risk, low-cost set of fixes tied to the audit-and-accountability requirements in the frameworks we report against. The real outcome is not the findings clearing; it is that every application we run becomes explainable after the fact, which is the baseline an audit expects.

The leadership question is whether logging is built into how new services ship, not whether today's finding count is zero. Done well, the fix comes with cost and data guardrails so it never becomes its own problem.

The application-logging findings reached the executive review after a nightly reconciliation workflow had failed silently for a month, reporting SUCCEEDED every night while skipping a third of the records, because logging was off and nobody could query what each state actually did. The lesson leadership drew was not about that one workflow. It was that the company runs applications, API gateways, query engines, build systems, data-movement pipelines, that cannot explain what they did, and that the frameworks the business reports against treat systems must log their activity as a baseline.

So the executive framing settled on two things. First, this is a low-risk, low-cost set of fixes whose real outcome is that every application becomes explainable after the fact, which is what an audit expects. Second, the fix must come with guardrails, lighter level in production, capped retention, redacted fields, so it never becomes its own cost or data problem. The question leadership keeps asking is not whether today's finding count is zero, it is whether logging is built into how new services ship, because a count that keeps creeping back up is the real signal.

On its own, any one of these findings is small and cheap to fix. They are on the report because of what they represent: applications we run that cannot explain what they did. Multiplied across a fleet of services, that is the difference between an incident or an audit producing a clear timeline and producing a shrug. The frameworks we report against treat "systems must log their activity" as a baseline, and this is a concrete place we are failing it.

There is a cost nuance leadership should know so the fix does not create a new problem. Logging at the most verbose level on busy services generates real storage cost and can capture sensitive data. So the correct instruction is not just turn it all on, it is turn it on, default to the lighter level in production, cap retention and redact. Done that way, the findings clear, the bill stays flat, and we stop running applications we cannot account for. The real question is whether this is built into how new services ship.