What fintech startups need to know about observability data retention requirements

Compliance guide on observability data requirements for fintech startups

Before most fintech startups hire their first compliance leader, engineers have already made dozens of decisions about logging, retention, monitoring, and data storage.

Do you have short retention windows for all of your logs, or are you maintaining an audit trail in advance? What exactly is required for observability data?

With this wave of new AI-native fintech startups, product development timelines have accelerated, and the volume of observability data being generated is unprecedented.

Adopting the right compliance strategy early can become a competitive advantage during customer security reviews and procurement evaluations.

In this piece, we'll cover how fintech startups can prepare to meet these data retention and accessibility requirements ahead of audits and upcoming enforcement deadlines.

At the end, we'll outline how teams can naturally achieve long-term data retention with Bronto for observability, which offers 12 month always-hot retention by default.

Reviewing key compliance standards & regulations

Traditional industry standards

Traditional industry standards like PCI DSS and ISO 27001 require organizations to maintain a thorough audit trail across their logs. PCI DSS is industry-specific and ISO 27001 is industry-agnostic, but they both set out compliance controls to allow organizations to prove their trustworthiness in the market.

PCI DSS: In December 2004, Visa, Mastercard, Amex, Discover and JCB merged their five separate card-security programmes into one standard covering any organisation that stores, processes or transmits cardholder data, maintained since 2006 by the PCI Security Standards Council. It is not law. It is enforced through your merchant agreement, which is why it can afford to be prescriptive and name specific numbers.

ISO 27001: A voluntary international certification standard introduced in 2005 and revised in 2022, covering how you run an information security management system. Because it has to fit any organisation in any sector, it sets out a risk-based approach rather than prescriptive controls, and an auditor tests you against the policies you wrote rather than against a fixed benchmark.

EU laws & regulations

EU laws like the Digital Operational Resilience Act (DORA) and the EU AI Act lay out additional requirements for organizations. New elements of the EU AI Act are still rolling out, and Angie Jones from the Agentic AI Foundation just released a great recap on what it means for teams building agents.

These EU laws are scoped respectively by sector and by use case, and organizations that fail to comply with their relevant requirements can face financial penalties.

DORA: The Digital Operational Resilience Act is EU law, in force since January 2025 and binding on financial entities operating in the EU, from banks and payment institutions to crypto-asset service providers. It also reaches the ICT providers those entities depend on. National regulators enforce it, and it specifies outcomes and deadlines rather than controls.

EU AI Act: EU law with requirements by use case rather than by sector. For fintech, it most specifically applies where AI is used to evaluate the creditworthiness of natural persons, and if AI is used in hiring or worker management. High-risk systems have logging and six-month retention requirements. It applies to deployers as well as model builders, and non-EU companies whose output is used in the EU.

Common compliance questions on storing & searching observability data

We reviewed the language in each of these and organized answers to the most common questions for building a monitoring and observability program that is compliance-ready.

How long do we need to retain telemetry data?

Set your retention period at twelve months and document it with a policy.

PCI DSS gives you a clear retention window. Requirement 10.5.1 sets twelve months minimum, with the most recent three months immediately available. If you are in card scope, treat that as a floor rather than a target.

The EU AI Act sets a specific number too, which will apply starting 2 December 2027. Article 26(6) and 19(1) require both deployers and providers to keep the logs a high-risk system generates for at least six months, to the extent those logs are under your control. For providers that are financial institutions, including fintechs building their own scoring models, logs must also be kept as part of the documentation already maintained under financial services law, which runs a good deal longer than six months.

DORA tells organizations only how to determine their retention policy. Article 12 of the RTS on ICT risk management requires them to set the retention period based on their business and information security objectives, including the reason they are recording the event, and the results of their ICT risk assessment.

ISO 27001 gives organizations flexibility in what they document. Annex A 8.15 asks you to determine the purpose of your logs, what you collect, and how long you keep it, then set that out in a topic-specific logging policy. Auditors measure you against that document rather than against a given benchmark.

For a startup, the practical move is to pick twelve months, because it satisfies PCI DSS Requirement 10.5.1 outright and is straightforward to defend under ISO 27001 and DORA. Most importantly, check that your documented policy and actual practices are in sync before an auditor can find gaps.

How much data needs to be immediately searchable vs. stored cold?

You need a minimum of 3 months of hot observability data, instantly searchable.

PCI DSS (Requirement 10.5.1) dictates twelve months retained and three months immediately available. Most architectures answer this with two tiers, three hot months and nine months in an archive that has to be restored before it can be searched.

DORA tells you how quickly you need to be able to query your data with incident milestones. A major incident requires initial notification within four hours of classifying it as major and no later than 24 hours from becoming aware, an intermediate report within 72 hours of that notification, and a final report within one month of the intermediate. Those anchors chain off each other rather than all running from detection.

The EU AI Act (Article 21(2)) requires that providers of high-risk systems give a competent authority access to the automatically generated logs on reasoned request, to the extent those logs are under their control. If you're building your own scoring model, then that request lands on you with whatever deadline the authority attaches to it.

ISO 27001 doesn't mention anything specific about retrieval speed for logs. Again, what's most important is that your policy matches your operations.

What observability signals do we need to care about for compliance?

Logs alone are not enough. Retain logs, traces, and metrics.

Logs are the only signal called out directly in the language of these frameworks, but their reporting requirements reach past logs to traces and metrics. Metrics are what let you say how bad an incident was, and ISO and DORA ask you to measure against history rather than against the moment. ISO 27001 (Annex A 8.16) requires monitoring systems and applications for anomalous behaviour, which requires establishing a baseline of normal behaviour to measure deviations against. DORA's classification criteria requires you to measure incident duration and service downtime against your recovery time objective, and classification is what kicks off the four-hour notification clock. Those measurements decide whether you need to file a report, or how you defend not doing so.

Traces are the one observability signal you cannot reconstruct after the fact. A payment that crossed a dozen services last March without trace context propagated through it cannot be reconstructed. The correlation has to happen while the request is running. PCI DSS Requirement 10.2.2 requires each entry to identify the affected data, system component, resource or service, which in a monolith is a complete answer and in microservices is a dozen disconnected entries. Lastly, DORA's final report requires root cause analysis, meaning the causal chain across all relevant services.

Ultimately, you need to keep all your signals. Logs retention is prescribed, metrics enable you to classify incidents, and traces are critical for a complete root cause analysis.

For each event, what fields are we required to record and retain?

Record and retain 6 critical metadata fields.

PCI DSS (Requirement 10.2.2) has minimum metadata requirements including:

• User identification
• Event type
• Date and time
• Success or failure
• Origination
• Affected data or resource

ISO 27001 (Annex A 8.15) asks each log entry to include, as applicable, user IDs, system activities, dates and times, device identity and location, and network addresses and protocols.

DORA tells you which events, not which fields to track. Article 12 of the RTS requires your logging procedures to identify the events to be logged and align the level of detail with detecting anomalous activity. The fields are yours to decide and yours to justify.

The EU AI Act gives you a purpose rather than fields. Article 12(2) requires logging that can identify risk situations or substantial modification, support post-market monitoring, and support the deployer's monitoring duty. The only prescribed field list, at Article 12(3), covers remote biometric identification and does not reach credit scoring.

It's worth noting that PCI DSS, ISO 27001 and DORA all require clock synchronization. Timestamps that disagree across services make the order of events unprovable, which is the thing the date and time field is there to establish.

What data are we required to mask or delete?

Mask account numbers and never store sensitive authentication data.

PCI DSS (Requirement 3.5.1) requires primary account numbers to be unreadable anywhere they are stored, logs included. Requirement 3.3.1 goes further for sensitive authentication data, meaning CVV, full track data and PINs: which must not be stored at all once the transaction is authorised.

Article 12 of the DORA RTS speaks to securing log data rather than what's in it, and the EU AI Act defers to data protection under GDPR. It's also worth thinking about GDPR's data minimisation guidance under Article 5(1)(c), instructing organizations to only collect and store observability data that is adequate and relevant to your purpose.

ISO 27001 (Annex A 8.15) says logs routinely contain PII and should be de-identified with data masking before going to a vendor.

On data masking

If you scrub your data too hard, you lose the user identification PCI DSS 10.2.2 requires, along with the ability to trace one actor across a year of logs. Scrub too little and cardholder data sits in your logging platform, which pulls it into your assessment scope.

We recommend replacing each identifier with a token, always the same token for the same input, so the real value is gone but the trail still connects. If the token is a hash of a card number, PCI DSS Requirement 3.5.1.1 requires it to be keyed.

Set those rules at the collector before you turn ingest on, because redaction only applies to data arriving after you configure it.

Are there identity and access requirements to ensure log integrity?

Make logs append-only, restrict who can read them, and alert on any change.

Nobody should be able to modify a stored record without it raising an alarm. Read access should be scoped tightly enough that you can hand an external auditor a view that excludes anything containing PII.

PCI DSS Requirement 10.3 breaks into read access limited to job-related need, protection from modification, prompt backup to a location that is difficult to alter, and change detection that alerts when existing log data changes. ISO 27001 Annex A 8.15 asks for the same and suggests append-only storage and cryptographic hashing. The DORA RTS requires documented measures for securing and handling log data at Article 12.

It's worth noting that the change-detection requirement targets changes to existing data. Appending new entries is not meant to trigger anything, which is why redacting at the collector before a record is written sits outside these requirements entirely.

What type of monitoring is required for logs & observability data?

Set automated reviews to run on a defined schedule, daily for anything in card scope.

PCI DSS has the most specific instructions on this topic. Requirement 10.4.1 details the daily review of security events and of logs from any component that stores, processes or transmits cardholder data, plus critical components and servers performing security functions.

An engineer checking a dashboard each morning is no longer a valid answer. As of March 2025, Requirement 10.4.1.1 insists that those reviews be automated. Requirement 10.4.2 covers everything else at a frequency you set through a targeted risk analysis, and 10.4.3 requires exceptions found during review to be addressed.

DORA specifies the capability rather than the inspection frequency. Article 10 requires mechanisms to promptly detect anomalous activities including network performance issues, alert thresholds that trigger your incident response process, automatic alerting to responsible staff, and multiple layers of control. It also requires that those detection mechanisms be tested regularly.

ISO 27001 goes wider than logs. Annex A 8.16 covers monitoring networks, systems and applications for anomalous behaviour, and asks that monitoring records themselves be retained for defined periods.

Starting in December 2027, the EU AI Act requires deployers of high-risk systems to monitor operation in line with the provider's instructions and retain the system's logs to support that monitoring.

Setting up automated reviews doesn't completely meet the requirements. You need records that prove that each review ran, and that a team member acted appropriately when the review detected an anomaly, especially for PCI DSS compliance.

What compliance burden does my observability vendor own?

You cannot offload compliance burdens to vendors.

By signing with a vendor, you gain observability capabilities but you do not offload any of your compliance burden to them. As you document your strategy, vendors are added to your list of things you have to document, assess, and monitor.

PCI DSS (Requirement 12.8) instructs you to write down who owns what and keep a vendor inventory describing each service with written agreements in which they acknowledge responsibility for the account data they hold. You must also run due diligence before you engage rather than after; monitor their compliance status at least annually; and document which requirements they manage, which you manage, and which are shared. An auditor will likely sample a few vendors and follow that chain end-to-end.

According to DORA, your observability provider is an ICT third-party provider that goes into the Register of Information under Article 28(3). You must conduct a concentration risk assessment before you sign and outline mandatory contract terms covering data protection, service levels, termination rights & incident assistance, with additional requirements wherever service supports a critical or important function.

ISO 27001 pulls vendors into your assessment. Annex A 5.19-22 covers information security in supplier relationships, what the agreements have to say, ICT supply chain risk, and ongoing monitoring of the services delivered.

The EU AI Act closes the reverse route. Buying a high-risk AI system from a vendor will not move the logging and retention duty onto them, because Article 26(6) places it on you as the deployer. That obligation applies starting 2 December 2027.

You should also ask about data residency, sub-processors and attestation reports before you sign with a vendor. With GDPR, the physical location of data is an important compliance concern independent of any data masking.

Observability costs compete directly with compliance goals

There's no language in PCI DSS, ISO 27001, DORA or the EU AI Act about how much you should spend on your observability costs. Maintaining a complete audit trail and minimizing monthly observability bills are typically in direct conflict.

Traditional observability vendors offer complex pricing with high ingestion, indexing, and computing fees and short-term default retention (30 days or less). As you upgrade to long-term retention plans that align with your compliance goals, the costs compound quickly.

With the sticker shock from high monthly bills, it isn't long before team members start sampling data, excluding workloads, and shortening retention windows. Each step is defensible on its own and each one is a compliance decision being made by a finance constraint, usually by people who are not compliance experts.

Nobody proactively decides to fail a PCI DSS assessment. They decide to cut a bill and it becomes the consequence during the audit. This is why it's critical to pick an observability vendor with predictable pricing and low data ingestion and storage rates.

How Bronto solves long-term data retention by design

Bronto is a new intelligent observability platform designed for long-term retention, making it possible to retain full-fidelity observability data without the cost hikes that often drive organizations toward aggressive sampling or short retention periods.

Bronto uses a custom polymorphic database to offer 100x higher data efficiency than tools like Datadog, which enables organizations to avoid these types of workarounds that risk compliance.

PCI DSS Requirement 10.5.1 asks for two things. Bronto answers both with one number. The standard wants twelve months retained and three months immediately available. Bronto's default is twelve months hot, across logs, metrics and traces. No tiering, no rehydration step, no separate archive to restore before you can search. Month eleven queries exactly the way month one does, which means the three-month distinction in the requirement stops being an architecture decision you have to make and then defend.

Sub-second search is what makes the reporting clocks survivable. Bronto uses Bloom filter indexing to return results in sub-second time across terabytes and seconds across petabytes. Set that against DORA's four hours to classify an incident and 72 hours to file an intermediate report. A thirty-minute query against restored archive data does not fit inside those windows. A sub-second query against twelve months of hot data does. That is the difference between reconstructing an incident and estimating it. Contentstack went from queries that timed out at thirty minutes to real-time analysis, an 800x improvement, while cutting logging costs in half and moving retention from two weeks to twelve months.

Full granularity, no sampling. Metrics keep full resolution for the full twelve months, including at high cardinality, and traces are not sampled at ingest. That is what makes DORA's downtime-against-RTO classification answerable after the fact rather than only in the moment, and that means the trace for a disputed transaction from four months ago actually exists when someone asks for it.

US and EU regions on AWS. Bronto runs in both, and does not send log data to third-party services.

Mask at the collector. For customers in regulated environments we recommend stripping cardholder data and PII at the agent or collector, so what reaches Bronto is already derisked. Bronto ingests from OpenTelemetry, Fluentd, Fluent Bit, Vector and Datadog agents, which is exactly where that redaction belongs.

Granular access control. Custom roles combine CRUD permissions across log management, dashboards, monitors, access management and billing, and can deny access to specific datasets or collections even where a role has general read permission. The pattern this enables is exactly the one auditors ask about: an external auditor role that cannot reach PII-related datasets, or a security-only role scoped to the security collection.

A pricing model that does not punish retention. Ingest is $0.10 per GB with twelve-month retention included, and every plan comes with a search quota of 100x monthly ingest volume. You never have to sit in a room deciding which telemetry is worth keeping.

Nitro provides the closest analogue to a fintech compliance profile. They moved from as little as three days of retention in some environments to 365+ days, meeting HIPAA, DORA, ISO 27001 and SOC 2 requirements, while reducing what they had been paying to extend Datadog retention. The retention change also opened up threat hunting across historical data and full incident timeline reconstruction, neither of which was possible before.

The evaluation checklist for observability vendors

Take these to any vendor, including us. If you are pre-assessment and trying to sequence the work, the two expensive things to retrofit are retention and redaction. Everything else on this list can be added later without reprocessing a year of data.

• What is the default retention, and what does twelve months cost at our projected volume?
• Is month twelve searchable directly, or does it require rehydration? How long does that take?
• What does a query across a full year return in, at our volume?
• Which regions can we pin our data to? Is any of it forwarded to a third party?
• What certifications and attestation reports can you provide for our supplier assessment, and what are you not certified for?
• If we mask sensitive fields before ingest, does your platform sit inside or outside our assessment scope? (Then take that answer to your QSA rather than the vendor's word for it.)
• Can we scope a role to exclude specific datasets, for an auditor or a contractor?
• Are metrics downsampled or rolled up over time, and at what age does that happen?
• Are traces sampled at ingest? If so, can we guarantee the trace for a specific disputed transaction exists?
• What evidence can the platform produce that automated log review occurred?
• What happens to our bill if transaction volume triples next year?

If twelve months of retention is already uncomfortable at today's volume, it will be unworkable at three times that. Retention is what gets cut, and that is how a budget decision becomes a compliance decision.

Getting started with Bronto for observability

Our team at Bronto can help you create an observability data strategy that aligns with both your business and compliance goals. With sub-second search and long-term retention, our platform makes it easier to store and search your logs, traces, and metrics without making compromises.

You can get started by booking a demo or starting a free 2 week trial to explore Bronto.