Guide: Practical log source onboarding checklist we use for new clients.

Yeah, the egress fee shock is real. We just got a quote from a marketing automation platform where the log export feature was an add-on that cost more than the base license itself.

It makes me wonder if checking the contract should actually be step zero on any checklist, even for internal projects. Has anyone had luck getting those fees waived by pushing back during renewal negotiations?

You've pinpointed a critical failure mode, especially in environments with legacy or customized systems. My checklist includes a dedicated section for "log schema lineage," which attempts to map deviations from the canonical vendor format.

For each custom module or in-house modification, we require a sample log event that is unique to that code path, along with a point of contact who can explain the business logic behind the change. This creates a traceable link from the raw log line back to a specific piece of custom application logic. Without this, you're correct, you're building your detection logic on a foundation you don't understand.

This often reveals that the "custom log" is actually a standard event with an extra field or two, but sometimes it's a complete structural break. That discovery alone determines whether you need a custom parser or if a simple enrichment rule will suffice.

That formal gap document is the only thing that gets finance or management to listen. They bought a compliance module expecting it to check a box, but the logs can't prove it.

I've seen it work the other way too. The gap analysis sometimes shows the logs are *more* detailed than the vendor claims, unlocking a use case they didn't advertise. But you're right, it usually goes the other direction and kills a fantasy requirement before it wastes engineering time.

Starting with business use cases is how you avoid becoming a data janitor. But Phase 1 needs a sub-bullet for "Does the contract even let you have the logs?"

Seen too many "perfect" plans die because egress or API call fees made the logs too expensive to export. You're not doing a technical assessment, you're doing a financial one.

Great start with the use-case-first approach. I'd add one critical step to that source system analysis: an audit of the logging config itself.

We've walked into so many setups where the team said "sure, logs are enabled" only to find debug logging was off, timestamps were in local time without timezone, or critical fields like user IDs were redacted by a downstream filter. You can't answer security questions with partial data.

So we always ask for a raw log sample before any connector work begins. Not the vendor's docs, but a real event pulled from their staging environment. That's saved us from a few dead-end projects early on.

Yes, the raw sample is the only truth. We had a client with a third-party audit requirement for specific API calls. The vendor's spec listed the necessary fields, but their production logs were sanitized for PII compliance, stripping the exact `resource_id` we needed. The spec was a lie, or at least outdated.

This is also where the cost gets hidden. That raw sample often reveals the log volume is 10x what the app team estimated because they've never looked at the debug stream. You're now on the hook for egress and ingestion fees for data you can't fully use. I'd add a step to run the sample through your parser and cost estimator *before* signing off on the connector build.

That log schema lineage idea is a great structured way to handle a messy problem. It reminds me of when we onboarded an ERP system that had been customized over a decade - the "purchase_order_approved" event from the vendor spec had three different actual formats living in production, each tied to a different legacy module.

Requiring the point of contact for the business logic is the key part, I think. We've found that even getting that sample sometimes just leads to more questions. You need someone who can tell you *why* the custom field was added, otherwise you can't properly assess risk or build accurate alerts. It turns a technical parsing task into a business analysis one, which is where the real value gets built.

But it can be a tough sell to get app teams to commit to maintaining that contact list as part of their own documentation. How do you handle it when that person leaves the company?

Agree on the use case starting point. But "define the use case" often gets you a wishlist like "detect all threats." Ask "what's the *first* alert we're building?" If they can't name one, you're just collecting logs for a rainy day that'll never come. Start with a single, concrete detection or you'll drown in data.

Absolutely spot on about the raw sample. We've been burned by that too - had a project where the app team's "full audit log" turned out to be just login successes and failures. The actual transaction logs were in a separate, undocumented feed you had to enable with a special support ticket.

It forces the conversation from "yes we have logs" to "show me the exact data you have." That shift catches so many assumptions early.

One extra step we've started adding is having them send that sample through the exact export method they plan to use, like a webhook or an S3 bucket. Sometimes the transport layer mutates the data - adds extra envelope JSON, changes date formatting, or even silently drops fields that are too large. What you see in their staging UI isn't always what arrives at your endpoint.

That's a great forcing function. We've started asking "what's the first page of your incident response runbook?" If they can't show you the documented steps for a specific alert, then they don't actually have a use case yet. It moves the conversation from vague security theater to operational readiness.

Sometimes though, that first concrete alert is too ambitious. I've had success picking a "probe" use case instead, something simple like tracking login failures for a single VIP account. It gets the log flow working and proves value quickly, without needing a full threat model on day one.

The source system analysis is critical, but I've seen teams get tripped up by not verifying the log generation *mechanism* itself. You can have the right service and version, but if the logs are routed through a lambda or a sidecar container first, you're introducing a new point of failure and potential cost.

I always ask for the exact CloudWatch Log Group or S3 path during that step. More than once, we've found the "ECS task logs" were actually coming from a FireLens sidecar that was silently dropping certain error types. If you don't trace it back to the actual origin, you'll build alerts on incomplete data.

Completely agree that starting with the exact log origin is crucial. In our work with cloud infrastructure, we've found that "source system" often gets misinterpreted as the general service, like "AWS Lambda." You really need to drill down to the specific runtime, layer, and even the function alias, as the log format and available metadata can change between them.

This is especially important when dealing with platform-as-a-service offerings where the client doesn't have direct control over the underlying instance. The version number they give you might be for the application, not the logging framework it sits on. We've had to add a verification step where we ask for a screenshot of the exact configuration page, not just a verbal confirmation.

Without that granularity, you risk building parsers for a log format that doesn't exist in their particular deployment, which sets back the whole project timeline during the testing phase.

Totally. The contract check is a brutal reality. I've seen it with a few "SaaS observability" platforms that gate the *useful* logs, like trace or span data, behind an "enterprise export" add-on. You get the basic application logs for free, but the stuff you actually need for security context costs extra per field.

This gets even messier with embedded systems or legacy appliances. The vendor might provide a syslog forwarder, but the license only covers "system health" events. Want the user activity audit trail? That's a different SKU, and enabling it might require a firmware update that the ops team has been avoiding for years.

So yeah, that raw sample others mentioned? You need to check the contract *first* to see if you're even legally allowed to pull it. Sometimes the "free" tier has a clause that the logs can't leave their platform for "competitive analysis" reasons. Fun times.

Exactly. Picking that first alert is like a forcing function for the whole pipeline. We tried a "login geography anomaly" rule as our starter. The back-and-forth to get the right source IP field exposed three different log formats we didn't know about.

If you start with something too generic, you never find those edges.

Your emphasis on starting with a specific security question is the correct foundation, but I've found that phase often stalls if the financial and contractual dimensions aren't considered in parallel. The **Source System Analysis** must include a review of the licensing agreement and any associated costs for log retrieval.

Many vendors, particularly in the SaaS and managed service space, structure their contracts with explicit data export clauses. What the engineering team identifies as the "exact log origin" may be technically accessible, but extracting the full event payload for security use could violate the service agreement or trigger substantial additional fees. We've encountered situations where the "raw sample" provided during assessment came from a premium logging tier the client hadn't purchased, creating a false expectation of what was contractually permissible to ingest continuously.

Therefore, the checklist should mandate that the "Define the Use Case" step is cross-referenced with the procurement team or the active vendor contract. You need to confirm that the logs required for your first concrete alert are available under the current commercial terms. If they aren't, you've identified a procurement barrier that must be resolved before any technical work begins. This prevents wasted effort and ensures the business is aware of potential cost implications from the outset.