Audit Logs, Part 1: Concepts of Audit Logging in Web Services — Fundamentals of Requirements Definition

What Should Audit Logs Record? Common Requirements in Tender Bids

Hello, I'm Otsuka, CTO at Liberogic.

When bidding on website or web service projects, requirements often include phrases such as "the system must be able to retain audit logs" or "logs must be stored for a certain period."

To meet these requirements, we select services, change plans, or add log storage options. But what exactly do we mean by "audit logs"?

In this article, we will take a closer look at these questions.

Logs Come in Many Forms

Although we often refer to them simply as "logs," there are actually several different types.

All of these are logs, but they record different information and serve different purposes.
For example, logs that record actions such as an administrator changing a user's permissions or a staff member publishing content are generally closer to what is called an audit log.

Treat failure investigation and evidence preservation as separate concerns

Logs serve two main purposes.

The first is logs used to find the cause when an outage or defect occurs.

They are used to investigate inquiries such as "I submitted the form yesterday but nothing arrived" or "errors occurred only during a specific time."

The other is a log for checking operation history after the fact.

It records information such as "who changed the settings," "when content was published," and "what actions were performed in the admin screen."

These two differ in both retention period and how they are used.

Keeping all logs searchable over a long period drives up costs. Conversely, if only recent logs are retained, the evidence needed for audits and incident investigations may be lost.

Designing them separately from the start leads to a more manageable architecture.

Turning "We need audit logs" into requirements

The term "audit logs" alone isn't enough to decide on a specific structure.

We start by clarifying the purpose, then work through which records are needed and how they should be stored.

"Logs are available" is not quite enough

When logs appear in a cloud service's admin console, it's easy to assume that "logging is in place."

However, what gets stored and for how long varies by service.

• Errors are retained, but administrator actions are not
• Viewable in the admin console, but deleted after a set period
• Forwarding externally requires a higher-tier plan
• Application-specific actions must be logged by your own team

Business records such as "who changed product information" or "which application data was processed" may not be fully traceable from cloud services alone.

If an RFP calls for "audit logs," there are at least the following points worth confirming.

Requirements Checklist

✅️ Which operations need to be logged?
✅️ Are they performed by end users or administrators?
✅️ Is the purpose troubleshooting or auditing?
✅️ How long should logs be retained?
✅️ Do you need to search logs regularly?
✅️ Who is allowed to view the logs?
✅️ Could the logs contain personal information?

If these points remain unclear when choosing services or plans, the architecture may end up larger than necessary, or important logs may not be recorded at all.

Logs Are Also Distributed in Modern Web Services

With traditional web servers, it was relatively straightforward to keep log files on the server itself.

Today, web services are increasingly built by combining multiple cloud services, such as CDNs, hosting, databases, headless CMS, and email delivery.

At Liberogic, we use not only AWS but also Cloudflare, Vercel, Supabase, microCMS, Kuroco, and others, depending on the project.

Because logs are stored separately in each service, you need to look across the entire system to understand what is actually being recorded.

Start by clarifying the purpose.

When you hear "we need audit logs," it can feel like a special service has to be introduced.

Of course, depending on the requirements, an external log management service or a long-term storage setup may be necessary. However, that doesn't mean you should build a large architecture from the start.

First, what should be recorded, why, and for how long?

Once that is clarified, the realistic approach is to separate what can be covered by standard features from what requires building additional mechanisms.

Next time, we'll take a general look at what kinds of logs are generated by services we frequently work with, such as AWS, Cloudflare, Vercel, Supabase, and headless CMSs.

Well then.