# SOC 2's 90-Day Log Myth: What Auditors Actually Sample

Robert Chen · August 21, 2026

> SOC 2's 90-Day Log Myth: What Auditors Actually Sample. Cutting log retention from 90 days to 14 days can reduce storage costs by up ...

| Takeaway | Detail |
| --- | --- |
| The 90-day log window is console folklore, not an audit standard | Cloud consoles retain event history for 90 days, but Type II examiners pull samples across the full observation period under review, so a console-sized window fails samples by construction |
| Cutting retention from 90 days to 14 days slashes storage spend | A simulation-based arXiv study (2601.11584) measured up to 78% lower log storage costs for the 90-to-14-day reduction |
| Short windows keep almost everything operationally useful | The same 90-to-14-day cut preserves more than 97% of operationally useful logs, while longer windows add storage cost and query overhead for diminishing returns (arXiv 2601.11584) |
| A 90-day default creates GDPR exposure on its own | Security logs are personal data, so running a 90-day window without a GDPR Article 30 record of processing is a violation independent of whether the window would have passed sampling |

Cutting log retention from 90 days to 14 days can reduce storage costs by up to 78%, according to a simulation-based study on arXiv (2601.11584). Yet the 90-day setting remains the default across cloud consoles, sustained less by evidence than by a belief that SOC 2 examiners require it. They don't. The 90-day log window is cloud-console folklore, not an audit standard — and treating it as one distorts both security budgets and compliance posture.

The gap is visible in the tooling itself. Amazon deletes CloudTrail event history as soon as the 90-day console window closes, while Type II examiners pull their samples from across the entire observation period under review. A logging stack tuned to what the console retains therefore fails most Type II samples by construction: the evidence an examiner requests has already been destroyed before the sample is ever drawn.

Privacy exposure compounds the problem. Security logs are personal data, so operating a 90-day window without a GDPR Article 30 record of processing is a violation in its own right, independent of whether the number would have passed. The operational excuse for long windows is thin anyway: the same 90-to-14-day cut preserves more than 97% of operationally useful logs, which is why deliberate retention beats inherited defaults.

![SOC 2's 90-Day Log Myth](https://static.mm-ais.com/article-images-ai/soc-2-s-90-day-log-myth-what-auditors-ac-ai-1eae29aa.jpg)

## The Sampling Trap

Kill the founding myth first: no clause in the AICPA's Trust Services Criteria mentions 90 days. A SOC 2 Type II engagement tests controls across the *full* observation period, and the service auditor draws attribute samples in the tens of items from that entire window, not from recent weeks. Three criteria pull log evidence directly: CC6.1 (logical access), CC7.2 (anomaly monitoring), and CC7.3 (incident response). Attribute testing is binary; a log entry that no longer exists scores as a control failure, not a documentation footnote.

Picture the actual draw. Fieldwork opens against the full observation period, and the request lists VPN authentication records for 10 randomly selected dates scattered from the earliest month to the latest, plus deprovisioning tickets for 5 separated employees spread across the same span. Evidence must come from production systems — system-generated exports with intact metadata. Retrospective screenshots assembled after the request arrives don't qualify, because they demonstrate nothing about what the control actually did on the sampled date.

So where did the 90-day habit originate? From console factory settings, not from any auditing standard. According to AWS's CloudTrail documentation, Event History retains 90 days by default — management events only. Google Cloud's Logging documentation sets a 30-day default. Microsoft's Log Analytics documentation defaults to 31 days of interactive retention. Teams read those numbers off their consoles and wrote them into policy as though they were requirements. According to the Cost-Aware Logging paper (arXiv 2601.11584), log data underpins observability, debugging, and performance monitoring in cloud-native systems, and it singles out retention configuration as a distinct problem area for small and early-stage deployments — precisely the teams least likely to override a default.

| Platform | Default retention | Scope of the default |
| --- | --- | --- |
| AWS CloudTrail Event History | 90 days | Management events only |
| GCP Cloud Logging | 30 days | Default log bucket |
| Azure Log Analytics | 31 days | Interactive retention |

The coverage math follows directly. With uniform sampling across the full observation period, only a minority of draws fall inside a 90-day retrievable window — meaning most requested evidence predates anything a default-configured environment can produce, and every one of those items lands as a failed attribute against CC6.1, CC7.2, or CC7.3. The trap is not that auditors ignore old logs; it is that factory settings guarantee you cannot show them.

The resolution is a two-tier design with deliberately asymmetric purposes. The hot tier — a searchable SIEM or log platform holding 90 days — serves live triage and the 72-hour breach-notification clock in Article 33 of the GDPR, where speed of search is the binding constraint. The cold tier — a WORM-immutable object archive holding everything older than the hot window — exists solely for auditor retrieval and incident reconstruction. Nobody queries it daily; it exists so that every sampled date in the observation period resolves to a producible record.

GDPR closes the loop. Authentication and security logs capture identifiers tied to individuals — user IDs, IP addresses, timestamps — so the retention design is itself a processing activity, and Article 30(1)(f) requires the ROPA entry to state explicit erasure time limits. The window you choose is therefore a compliance artifact, not merely an ops setting: an undocumented window is unlawful regardless of its length, while a documented two-tier split satisfies both regimes at once. Write both tiers into the ROPA before the observation period starts.

| Auditor request | Criteria ref | Hot tier (≤90 days) | Cold tier (beyond 90 days) |
| --- | --- | --- | --- |
| VPN authentications, 10 scattered dates | CC6.1 | Live query for recent dates | WORM export for earlier dates |
| Anomaly-monitoring alert history | CC7.2 | Live SIEM search | Archived alert records |
| Deprovisioning tickets, 5 separated employees | CC7.3 | Recent separations | Older separations via immutable copy |

![The Sampling Trap — SOC 2's 90-Day Log Myth](https://static.mm-ais.com/article-images-ai/soc-2-s-90-day-log-myth-what-auditors-ac-ai-cfa9294c.jpg)

## The Receipts

Every number in the retention debate comes from a document that says something other than what people remember. Pull the receipts in order and the two-tier configuration stops looking like a compromise and starts looking like the only answer the sources actually support.

Twenty-five items. According to the AICPA's Audit Guide for Service Organizations, Type II testing is attribute sampling over the reporting period, with commonly used sample sizes around 25 items. The population is the period, not the quarter — an auditor drawing 25 items pulls from month eleven as readily as month one. That is the arithmetic underneath the sampling trap: a hot tier that expires early doesn't weaken the control narrative, it deletes the population the sample is drawn from.

The second receipt explains where the folklore originated. PCI DSS v4.0 Requirement 10.5.1 requires audit logs to be retained well beyond the analysis window, with at least 3 months immediately available for analysis. That three-month-online floor is a cardholder-data rule, and it is the number people half-remember: somewhere between the QSA world and the SOC 2 world, "3 months online" collapsed into "ninety days is enough." PCI says nothing about SOC 2, and no SOC 2 standard contains a ninety-day figure.

The third receipt has legal teeth. Article 30(1)(f) requires the ROPA to state "where possible, the envisaged time limits for erasure" for each category of personal data — so an undocumented window is not a documentation gap, it is a record that fails the article's own text, whatever its length. Article 30(5)'s exemption is narrower than compliance folklore holds: it covers only smaller organizations whose processing is occasional, and security logging is continuous by definition. Virtually no SaaS platform clears that bar.

Why logs count as personal data at all: the CJEU held in Breyer v Germany that dynamic IP addresses are personal data. Authentication logs, access logs, and audit trails are assembled from those addresses and the identifiers behind them — squarely inside Article 30's record-keeping scope.

The fourth receipt cuts the other way, and it is the one CISOs under-cite: EU regulators tolerate long windows when they are written down. According to CNIL's guidance, security and connection logs may be kept up to one year on proportionality grounds, and telecom operators may retain for one year under CPCE article L.34-1. A one-year archive is defensible; an unrecorded one is not.

The last receipt is a vacuum. NIST's log-management guidance and the AU-11 control in its catalog both leave retention "organization-defined" — no numeric floor, no default. Where the standard is silent, the settings page decides, which is exactly how vendor console defaults became de facto policy in lieu of a written standard. A retention period nobody chose is still a choice — just an unaudited one.

| AICPA Audit Guide | Type II testing is attribute sampling over the reporting period; ~25 items | Draws span the full period by design |
| --- | --- | --- |
| PCI DSS v4.0 Req. 10.5.1 | Retain audit logs well beyond the analysis window; at least 3 months immediately available for analysis | Origin of the "3 months online" conflation — a PCI rule, not a SOC 2 clause |
| GDPR Art. 30(1)(f) | ROPA must state "where possible, the envisaged time limits for erasure" | An undocumented window is unlawful at any length |
| GDPR Art. 30(5) | Exemption only: smaller organizations and occasional processing | Continuous security logging disqualifies SaaS platforms |
| CJEU Breyer | Dynamic IP addresses are personal data | Auth, access, and audit logs sit inside Art. 30 scope |
| CNIL guidance; CPCE art. L.34-1 | Security and connection logs up to 1 year; telecom operators 1 year | Long retention is defensible — if recorded |
| NIST log-management guidance; control AU-11 | Retention is "organization-defined," no numeric floor | The vacuum vendor console defaults silently filled |

The receipts converge on one move, and it belongs on the calendar, not the wiki: before the observation period opens, record both tiers — the hot/searchable window and the WORM-immutable archive — as the envisaged time limits for erasure in the Article 30 ROPA entry. Every source above either demands that entry or permits the retention it describes.

![The Receipts — SOC 2's 90-Day Log Myth](https://static.mm-ais.com/article-images-pixabay/soc-2-s-90-day-log-myth-what-auditors-ac-f54dd34c.jpg)

## Four Retention Architectures, One Winner

Score the four retention designs against what a Type II sample actually does, and two are eliminated before cost enters the discussion. The rule the comparison encodes is structural, not economic: any architecture whose retrievable window is shorter than the observation period fails sampling by construction. That removes the cloud-default designs (A and D) outright for any full-length Type II period — which today means every standard engagement. What makes A seductive is that the default feels enforced; AWS's own documentation describes enforcement through two named constructs, Bedrock Projects and service control policies. But a service control policy is a deletion schedule, not an evidence store: it governs how long a log lives, not whether anyone can retrieve it afterward. The full-coverage designs (B and C) both retrieve 100% of draws; everything separating them is downstream of that fact.

| Architecture | Full-window sampling retrievability | Hot-tier growth behavior | Art. 30(1)(f) documentation fit | Auditor restore latency |
| --- | --- | --- | --- | --- |
| A — cloud-default hot only (30–90 days) | Partial; every draw older than the window is unretrievable | Flat, but flat because evidence is destroyed at the edge | Poor; one default window, typically never documented | Fast for recent draws; impossible for older ones |
| B — full-period all-hot in the SIEM | 100% of draws | Grows linearly with observation length; query overhead climbs with it | Adequate; one tier, one erasure time limit | Immediate, native hot search |
| C — 90-day hot + WORM archive | 100% of draws | Hot plateaus at 90 days of ingest; only the archive grows | Strong; two named tiers map to two erasure time limits | Hours via archive restore; well inside evidence deadlines |
| D — 30-day hot, no archive | Fails most draws in any full-length period | Truncates continuously; oldest evidence goes first | Poor; shortest window, least to document | Fast, but only inside the window |

The economics of C are structural. According to the arXiv simulation on cost-aware log retention (the paper unpacked in the receipts section), cutting the hot window from 90 to 14 days lowered log storage costs by up to 78% — hot-tier spend is where retention cost concentrates, and it scales steeply with window length. The same study found longer windows deliver diminishing operational returns while disproportionately increasing storage cost and query overhead, which is precisely B's tax: every investigation scans the full corpus. C exploits that gradient instead of paying it — hot spend plateaus at the 90-day mark no matter how long the observation runs, so search-tier cost stays flat while evidence coverage extends across the full period. Treat the 78% as a modeled ceiling; the study is an 8-page simulation with three tables, not field telemetry. The direction, though, is not in dispute.

C wins on every criterion except the one that matters least. It alone scores maximum sampling coverage, maps cleanly onto the ROPA — two named tiers translate directly into two erasure time limits under Art. 30(1)(f) — and restores archived evidence in hours, typically holding a sub-24-hour turnaround when a sample request lands mid-fieldwork. B is the legitimate runner-up in exactly one case: the small shop whose annual ingest volume is low enough that tiering overhead — a second storage class, a restore runbook, a second ROPA line — costs more in engineering time than an all-hot year costs in storage. Everyone else pays B's query-overhead penalty for coverage C delivers at flat search-tier cost.

When your constraints differ from the standard case, re-rank with a fixed hierarchy rather than ad-hoc judgment:

| Priority | Criterion | The test | What failure looks like |
| --- | --- | --- | --- |
| 1 | Sampling coverage | Retrievable window spans the observation period | Exceptions on every draw past the window |
| 2 | ROPA mappability | Every tier names an erasure time limit under Art. 30(1)(f) | An undocumented window is unlawful at any length |
| 3 | Restore SLA | Archived draws return inside the evidence deadline | Fieldwork stalls waiting on retrieval |
| 4 | Cost | Search-tier spend stays flat as the period extends | The bill scales with observation length |

A three-month first-year observation window genuinely reshuffles the field: architecture A suddenly passes the coverage test because its window now spans the entire period. It still loses on ROPA mappability, and it archives nothing for the year-two period that will run longer. Re-rank within the hierarchy; never move cost to the front, because the first three criteria are pass/fail tests against the sampling and GDPR regimes and only cost is a continuum. Teams that invert the order talk themselves into A every time.

The cost of choosing wrong is deferred, which is what makes it dangerous. Unremediated sampling exceptions from a short window push the service auditor toward qualified report language, and a qualified opinion does not stay in the report — it resurfaces in bridge letters during M&A diligence, where buyer-side advisors read it as a control-environment defect and price it into the deal. Architecture A looks cheap at audit time because its failure mode stays invisible until someone pulls a draw from month nine. The bill arrives at exit, not at fieldwork.

![Four Retention Architectures, One Winner — SOC 2's 90-Day Log Myth](https://static.mm-ais.com/article-images-pixabay/soc-2-s-90-day-log-myth-what-auditors-ac-912a431b.jpg)

## What the Data Doesn't Tell You

The strongest number supporting the two-tier configuration was never collected anywhere near an audit. According to the January 2026 arXiv preprint 2601.11584, compressing a hot log tier from ninety days down to fourteen preserved more than 97% of operationally useful logs. Read that claim with precision: it measures operational usefulness — debugging, alerting, incident reconstruction — not evidentiary sufficiency. Nothing in that paper tests whether a service auditor accepts a compressed archive as sampleable evidence, and nothing in it addresses GDPR documentation duties. Treating it as compliance evidence is a category error, and this section exists to fence it off.

**Limitations of the evidence.** Three structural ones. First, it is a preprint — posted in January 2026, without peer-reviewed replication, in a literature that carries survivorship bias: retention cuts that silently destroyed needed evidence rarely produce papers. Second, "operationally useful" is defined by downstream engineering tasks; an auditor's definition — completeness, integrity, and retrievability across the full observation period — is stricter and has not been tested against the 97% result. Third, the measurement comes from high-volume operational telemetry, the chattiest log class that exists, which matters for the next point.

**Variance across cases.** Signal density, not raw volume, determines what a proportional cut destroys. In chatty infrastructure streams, redundancy is enormous and the 97% figure plausibly transfers. In environments dominated by rare, low-frequency security events — privileged-access changes, failed-authentication clusters, configuration drift — the informative tail is precisely what aggressive compression discards first. Same percentage, opposite outcome. Variance also runs through engagement design: shorter observation periods reduce the marginal value of the archive tier, while multi-framework tenants stacking SOC 2 alongside ISO or PCI assessments extract more value from the same immutable store. Neither direction changes the rule; both change what the archive is worth.

**The misreading to kill.** A variant is circulating in platform teams: the 97% figure as license to shrink the searchable tier toward that fourteen-day mark. The paper compressed within an operational window; it did not license shrinking the sampleable surface. Auditors draw from the entire observation period regardless of what engineers find useful — the vendor default and the audit requirement are different quantities, and conflating them is how teams reach fieldwork with most of the observation period unsampleable, the gap quantified earlier in this guide.

**When the rule breaks.** Three cases where the canonical configuration genuinely bends:

| Edge case | What breaks | Fix that preserves the rule |
| --- | --- | --- |
| Litigation or regulatory hold | Scheduled WORM expiry lawfully purges records under a preservation duty | Hold flag suspends lifecycle rules; annotate the ROPA entry "subject to legal hold" |
| Rare-event-dense logging | The 97% utility figure may not transfer to low-frequency security signals | Treat the archive tier as the primary evidence source; test retrieval before fieldwork |
| Sector overlay with longer minimums | Archive tier sits below a statutory recordkeeping floor | Extend the archive tier to the longest applicable limit; keep the two-tier shape |
| Short, fixed observation period | Archive premium buys no additional sample value | Premium justified only when extension risk or shared multi-framework use is real |

Note what none of these cases do: they attack lazy readings of the supporting evidence, not the two-tier structure itself. The actionable residue is one sentence. Before fieldwork, append to the Article 30 entry: both erasure time limits, each suspended during any active legal hold. That clause keeps the ROPA truthful on the day the purge pauses — which is, not coincidentally, the day an examiner is most likely to read it.

![What the Data Doesn't Tell You — SOC 2's 90-Day Log Myth](https://static.mm-ais.com/article-images-pixabay/soc-2-s-90-day-log-myth-what-auditors-ac-dc559431.jpg)

## What the 90-Day Math Hides

Some first-year Type II reports never test a full year. A set of firms issue a 3-month observation period with a 9-month roll-forward, and against a 90-day hot window every possible draw lands inside retention — on that engagement shape, the short window technically covers everything. The mostly unsampleable share derived above is a property of the full-length engagement, not a law of audit physics. That makes auditor selection a retention decision: when you vet firms, ask what first-year period structure they issue, because the answer moves your sampling exposure more than any vendor setting. The configuration that holds across every period shape is still the two-tier 90-day design.

The uniform-sampling assumption deserves equal skepticism. Auditors stratify draws toward high-risk intervals — post-incident weeks, change freezes, quarter-end — so real-world hit rates against a 90-day window can exceed the uniform baseline or undershoot it, because weighting decides: a firm that weights recent months heavily concentrates draws inside the window, while one chasing an old incident pulls them outside it. Either way, stratification reweights draws across the full observation period; it never truncates it. The sample still reaches the earliest month — a vendor default is not a sampling behavior.

State the GDPR counter-evidence plainly: to date, no major EU data protection authority fine targets a documented full-year security-log window. Published sanctions concentrate on indefinite retention and on processing with no ROPA entry at all. The GDPR half of the case therefore rests on the letter of Art. 30(1)(f), not on observed penalties — the duty is documentary, which is why the ROPA entry, not the fine, is the artifact to optimize. Undocumented is unlawful at any length; documented has, so far, gone unsanctioned.

The archive tier creates its own collision. WORM storage locked in compliance mode cannot be shortened — by you or the vendor — which collides head-on with Art. 17 erasure requests when personal data lands in an immutable log. Governance-mode locks preserve the immutability story but let privileged roles shorten retention, which an auditor can read as a control weakness; crypto-shredding destroys the encryption key instead of the object, but the auditor must accept key-destruction records as proof of erasure. As of this writing, no public benchmark has settled which trade-off Type II auditors accept, so name your choice in the ROPA entry beside the retention tiers.

Duration has a value ceiling. Shared service accounts, NAT'd egress IPs, and ephemeral container IDs can leave a full year of retained logs forensically weak — the event is recorded, but which human or workload caused it is unrecoverable. Extending the window fixes evidence availability, not evidentiary value; no retention number compensates for unattributable events. Run the cheaper check first: confirm the identity chain — account to NAT mapping to container lifetime — outlives your shortest-lived identifier, or the archive stores questions instead of answers.

Finally, portfolio drift. FedRAMP-aligned and similar government environments often push retention well beyond the two-tier baseline; government regimes tend to define scope broadly — call records, email, browsing history, location data — with horizons to match. Retention design, in its standard formulation, weighs legal and privacy concerns against economics and need-to-know, and switching regimes switches the weights. So the two-tier 90-day design is the SOC 2-plus-GDPR optimum, not a universal constant: where FedRAMP applies, the archive tier is a floor, not a ceiling.

Read the edge cases as one column and the pattern is directional: nothing licenses a shorter window, and every deviation from the pair is additive.

| Edge case | What actually moves | Verdict for the two-tier design |  |
| --- | --- | --- | --- |
| First-year 3-month period + 9-month roll-forward | Observation-period length, not the window | 90-day hot tier covers every draw; keep the archive tier for the Art. 30 entr ``` Frequently Asked Questions How many items does a SOC 2 Type II auditor actually sample, and from what time span? According to the AICPA's Audit Guide for Service Organizations, Type II testing commonly uses attribute samples of around 25 items drawn from across the full observation period, meaning an auditor pulls from month eleven as readily as month one. If I rely on AWS CloudTrail Event History, will my logs still exist when the examiner asks for them? No — Amazon deletes CloudTrail event history as soon as the 90-day console window closes, so evidence requested from earlier in the observation period has already been destroyed before the sample is ever drawn. How much storage cost could we save by dropping log retention from 90 days to 14 days? A simulation-based arXiv study (2601.11584) measured up to 78% lower log storage costs for the 90-to-14-day reduction while preserving more than 97% of operationally useful logs. Isn't the 90-day requirement actually coming from PCI DSS? PCI DSS v4.0 Requirement 10.5.1 requires audit logs to be retained with at least 3 months immediately available for analysis, but that three-month-online floor is a cardholder-data rule that says nothing about SOC 2, and no SOC 2 standard contains a ninety-day figure. As a small startup, can we skip the GDPR Article 30 record of processing for our security logs under the Article 30(5) exemption? Article 30(5)'s exemption covers only smaller organizations whose processing is occasional, and because security logging is continuous by definition, virtually no SaaS platform clears that bar. Can we assemble screenshots of old dashboards after an auditor requests evidence for a sampled date? No — evidence must come from production systems as system-generated exports with intact metadata, because retrospective screenshots assembled after the request arrives demonstrate nothing about what the control actually did on the sampled date. Quick answers Does any clause in the AICPA's Trust Services Criteria require a 90-day log retention window? | No — no clause in the Trust Services Criteria mentions 90 days; the window is cloud-console folklore, not an audit standard. |
| How does a SOC 2 Type II examiner sample log evidence? | Type II examiners draw attribute samples of roughly 25 items from the entire observation period, so evidence must exist for dates scattered from the earliest month to the latest. |  |  |
| What happens when a sampled log entry no longer exists because console retention expired? | Attribute testing is binary, so a log entry that no longer exists scores as a control failure against CC6.1, CC7.2, or CC7.3, not a documentation footnote. |  |  |
| What did the arXiv study find about cutting log retention from 90 days to 14 days? | It measured up to 78% lower log storage costs while preserving more than 97% of operationally useful logs. |  |  |
| Why can a 90-day default create GDPR exposure on its own? | Security logs are personal data, so running a 90-day window without a GDPR Article 30 record of processing stating explicit erasure time limits is a violation independent of whether the window would have passed sampling. |  |  |

Also worth reading: **GDPR Audit Prep: Centralized vs Federated May Cut Time 40%**: [GDPR Audit Prep: Centralized vs](https://opensilo.co/blog/gdpr-audit-prep-centralized-vs-federated-may-cut-time-40.php) · **Data Retention: 3 Governance Models vs. Time-to-Market**: [Data Retention: 3 Governance Models](https://opensilo.co/blog/data-retention-3-governance-models-vs-time-to-market.php) · **Wiki ROI: The Truth Behind 40% Deflection and 3-Day Onboarding**: [Wiki ROI: The Truth Behind](https://opensilo.co/blog/wiki-roi-the-truth-behind-40-deflection-and-3-day-onboarding.php)

### Related reading

- [2026 Data Mesh: Federated Routing Risk, 62% Exposure Spike](https://opensilo.co/blog/2026-data-mesh-federated-routing-risk-62-exposure-spike.php)
- [GDPR Audit Prep: Centralized vs Federated May Cut Time 40%](https://opensilo.co/blog/gdpr-audit-prep-centralized-vs-federated-may-cut-time-40.php)
- [Microsegmentation Overhead: 12ms Latency and 18% Cost in 2026](https://opensilo.co/blog/microsegmentation-overhead-12ms-latency-and-18-cost-in-2026.php)
- [Un-Siloing Eng & Sales Data: 38% Faster Launches (Forrester)](https://opensilo.co/blog/un-siloing-eng-sales-data-38-faster-launches-forrester.php)
- [Federated Data Catalogs: 40% Discovery Gain and Hidden Risks](https://opensilo.co/blog/federated-data-catalogs-40-discovery-gain-and-hidden-risks.php)
- [RAG Pipeline: 5 Internal Data Access Gaps That Kill Accuracy](https://opensilo.co/blog/rag-pipeline-5-internal-data-access-gaps-that-kill-accuracy.php)

### Latest

- [2026 Data Mesh: Federated Routing Risk, 62% Exposure Spike](https://opensilo.co/blog/2026-data-mesh-federated-routing-risk-62-exposure-spike.php)
- [GDPR Audit Prep: Centralized vs Federated May Cut Time 40%](https://opensilo.co/blog/gdpr-audit-prep-centralized-vs-federated-may-cut-time-40.php)
- [Microsegmentation Overhead: 12ms Latency and 18% Cost in 2026](https://opensilo.co/blog/microsegmentation-overhead-12ms-latency-and-18-cost-in-2026.php)
- [Un-Siloing Eng & Sales Data: 38% Faster Launches (Forrester)](https://opensilo.co/blog/un-siloing-eng-sales-data-38-faster-launches-forrester.php)

Canonical: https://opensilo.co/blog/soc-2s-90-day-log-myth-what-auditors-actually-sample.php
Markdown: https://opensilo.co/blog/soc-2s-90-day-log-myth-what-auditors-actually-sample.php/index.md