Stability Program Data: Moving From Spreadsheets to a Managed System

Why Stability Programs Outgrow Spreadsheets

Stability work has a property that most quality control work does not: it runs for years, and every result only makes sense in the context of results that came before it. A release test answers a question about one batch today. A stability result at the 24-month time point answers a question about how that batch has changed since time zero, compared with how other batches changed, under a specific storage condition, measured by a method that may have been revised twice since the study started. The value of the data is in those connections.

Spreadsheets are good at holding numbers and poor at holding connections. That is the core of the problem. A single well-built workbook for a single study can be accurate and well controlled. The difficulty is that a stability program is never a single study. It is a portfolio of studies that overlap in time, share methods and specifications, and feed into the same annual product reviews and regulatory filings.

What a Stability Program Has to Hold

The regulatory requirements describe a data structure, even if they never use that word. Under 21 CFR 211.166, a firm must have a written stability testing program that includes sample size and test intervals based on statistical criteria for each attribute, storage conditions for retained samples, reliable and specific test methods, and testing in the same container-closure system used for the marketed product. The results must be used to set storage conditions and expiration dates.³ Section 211.137 then requires that each drug product carry an expiration date determined by that stability testing, tied to the storage conditions on the labeling.⁴

ICH Q1A(R2) adds the time structure. For products with a proposed shelf life of at least 12 months, it says long-term testing should normally be done every 3 months over the first year, every 6 months over the second year, and annually after that through the proposed shelf life. At the accelerated condition, it recommends a minimum of three time points, including the initial and final points.¹ ICH Q1E then describes how to evaluate those data: regression analysis, tests of whether batches can be pooled, and one-sided or two-sided 95 percent confidence limits to estimate where the mean trend meets the acceptance criterion.²

For commercial products, EU GMP Chapter 6 requires an ongoing stability program described in a written protocol that runs to the end of the shelf life. The protocol must list the number of batches, test methods, acceptance criteria, container closure, time points, and storage conditions. Unless justified otherwise, at least one batch per year of every strength and every primary packaging type goes on stability. Out-of-specification results and significant atypical trends must be investigated, and a summary of all the data, including interim conclusions, must be written, maintained, and periodically reviewed.⁵

Put those requirements together and you have a many-to-many structure: products, strengths, and packs; batches; protocols and their versions; storage conditions; time points; pulls; tests; results; specifications and their versions; and investigations. Each connection matters to an inspector.

Why the Volume Grows Faster Than the Team

Some illustrative arithmetic helps here. This is not a benchmark, only a way to see how quickly the numbers grow. Take one commercial product with three strengths and two primary packaging types and a 36-month shelf life. Under the Chapter 6 default of one batch per year per strength and pack, that is six new ongoing studies each year. Following the Q1A(R2) schedule, each study has long-term pulls at 3, 6, 9, 12, 18, 24, and 36 months after the initial test. Because each study runs for three years, by year three you have roughly eighteen ongoing studies in flight for this one product, before counting development studies, registration batches, post-change studies, or intermediate conditions. Multiply by a portfolio and the pull calendar alone becomes a scheduling system.

In a spreadsheet model, that calendar usually lives in a separate tracker, apart from the result workbooks, often owned by a different person. The tracker says a pull is due. The result workbook says what was measured. Nothing links the two except the diligence of the people updating both.

Where the Spreadsheet Model Fails in Practice

The failures that matter are rarely formula errors. They are structural:

• No clock between pull and result. A sample is pulled from the chamber on schedule, but testing slips. Nothing in the workbook shows how long the sample has waited.
• Specification versions that drift. A specification is tightened. Old studies are still compared against the old limit in one workbook and the new limit in another, and the trend chart does not show which is which.
• Copies instead of records. The annual product review author copies data into a new workbook to build trend charts. Now there are two sources, and corrections made in one do not reach the other.
• Time points that are labels, not dates. “T12” in one file and “12M” in another, with the actual pull date recorded somewhere else, or not at all.
• Trending that happens once a year. The only time anyone looks across batches is when the annual review is due, which means an unusual result can go unexamined for months.

A July 2025 FDA warning letter to Glenmark Pharmaceuticals shows what the first of these looks like when it reaches an inspector. FDA cited the firm under 21 CFR 211.166(a) for failing to follow its written stability procedure, noting that testing was overdue by 3 months or longer for a large proportion of samples (FDA redacted the number of samples involved). The letter states that in multiple instances, dissolution failures in potassium chloride extended-release capsules were not observed for approximately 100 days after the stability samples were pulled, which delayed field alert reports and recalls.⁹ That gap between pull and result is exactly the kind of thing a managed system can show on a dashboard every morning, and exactly the kind of thing a folder of workbooks hides.

Stability findings are not rare. ECA Academy reported in 2020 on a published evaluation showing that complaints about inadequate stability testing appeared in about every fifth FDA warning letter in fiscal years 2016, 2018, and 2019.¹¹ The examples ECA gave were mostly about inadequate or missing programs rather than data handling, but the point stands: stability is an area inspectors look at closely, and the evidence they ask for is data.

The Regulatory Frame in 2026

Before designing anything, it helps to be clear about which rules are in force and which are coming. A system built today will run for a decade, so it should fit the current rules and be ready for the revised ICH guideline without being built to a draft.

The Rules in Force Today

As of late September 2026, the ICH stability series that regulators apply is still the existing set: Q1A(R2) for the core stability testing design, Q1B for photostability, Q1C for new dosage forms, Q1D for bracketing and matrixing, Q1E for evaluation of stability data, and Q5C for biotechnological and biological products. In the United States, 21 CFR 211.166 and 211.137 set the binding requirements for commercial drug products.³⁴ In the EU, Chapter 6 of the GMP Guide sets the ongoing stability program requirements, and Chapter 6 also requires that some data, including test results, be recorded in a way that permits trend evaluation, with out-of-trend and out-of-specification data addressed and investigated.⁵

Two details from Q1E matter directly to system design. First, when testing whether data from different batches can be combined, Q1E says the tests for common slope and intercept should use a significance level of 0.25, to make up for the low statistical power of a typical stability study with few batches.² Second, Q1E limits how far a shelf life can be extrapolated beyond the long-term data. In the cases it describes, for example where there is no significant change at the accelerated condition and the proposal is backed by statistical analysis and supporting data, a proposed shelf life can be up to twice, but not more than 12 months beyond, the period covered by long-term data.² A system that is expected to support shelf-life evaluation has to do these calculations the way Q1E describes, or export clean data to a validated tool that does.

Where the ICH Q1 Revision Stands

ICH is replacing the Q1A through Q1F series and Q5C with a single consolidated guideline,⁸ titled “ICH Q1 Stability Testing of Drug Substances and Drug Products.”⁷ The draft was endorsed at Step 2 on 11 April 2025. EMA released it for public consultation on 30 April 2025 with a comment deadline of 30 July 2025.⁶ ICH’s work plan dated February 11, 2026 records the public consultation period as April to September 2025 across regions, lists Plenary Working Party engagement in September 2026, and targets Step 3 sign-off and Step 4 adoption in November 2026, with training materials due in June 2027.⁷

The FDA rapporteur for the working group, Dr. Ashutosh Rao, presented the status at CASSS WCBP 2026. His slides say comment resolution is in progress, that finalization of the Step 3 draft is expected by November 2026, and that Step 4 adoption and Step 5 implementation will follow. The same slides carry a disclaimer that the draft is expected to change based on public comments.⁸

What the Draft Signals for Data Systems

Even as a draft, the consolidated Q1 shows the direction. Three parts are relevant to how stability data should be managed:

• Data evaluation and extrapolation. Section 13 of the draft describes extrapolation of shelf life supported by statistical analysis, for example linear regression with a 95 percent confidence limit, and expects any observable trend to be justified. Where a shelf life is extrapolated, the draft says primary studies should continue after approval, and that the manufacturer’s pharmaceutical quality system should be able to detect and manage confirmed changes in stability trend and out-of-specification results, with corrective and preventive action as described in ICH Q10.⁶
• Stability modeling. Annex 2 of the draft covers enhanced stability models. It says the statistical approach should be clearly described and justified, and that ongoing monitoring of new stability data after approval should be managed by the quality system, which should be able to detect unexpected changes in trend relevant to any model used to set a shelf life.⁶
• Ongoing stability studies. Section 15.2 describes ongoing studies at long-term conditions on an annual basis, to monitor stability characteristics and examine trends. It says at least one production batch of the drug substance, and one production batch of each strength of the drug product covering the container closure systems, should be added each year unless none is produced.⁶

The common thread is trend detection as a quality system capability, not an annual exercise. A company that can show its stability data are structured, current, and trended as results arrive will be in a better position when the final guideline arrives, whatever its exact wording.

The Data Model: Studies, Conditions, Pulls, and Results

The single most important part of moving off spreadsheets is the data model. A commercial stability system will come with one, and most are similar at the top level. The work is in understanding it well enough to make the configuration decisions that the vendor cannot make for you, and in mapping your legacy data into it without losing meaning.

The Core Entities

The table below lists the entities most stability systems use, what each one holds, the shortcut spreadsheets usually take, and why the difference matters.

Design Decisions That Are Hard to Change Later

Most configuration can be adjusted after go-live. A few decisions are expensive to reverse because they are built into every record created after them. Make these deliberately, document the rationale, and get quality and statistics sign-off before configuration starts.

How Time Zero Is Defined

Is time zero the date of manufacture, the date of release testing, or the date the samples were placed in the chamber? Different companies choose differently, and some choose differently for drug substance and drug product. The choice affects every time value used in regression and every expiration date calculation. Whatever you choose, the system should store all three dates, and the rule for which one drives the time axis should be a configured, documented setting, not a habit.

Pull Windows and Actual Time

A protocol schedules a 12-month pull. The sample is pulled at 12 months and nine days. Should the regression use 12.0 months or the actual elapsed time? Should the system flag a pull outside a defined window? Store the scheduled date, the window, and the actual date for every pull. Decide, with your statistician, whether evaluations use nominal or actual time, and apply the rule consistently. Legacy data often have only nominal time points, which becomes a migration question.

Censored Results

Impurity results reported as “less than the limit of quantitation” are common, especially early in a study. In spreadsheets they are often typed as text, which breaks any formula that touches them, or replaced with zero or with the limit value by whoever built the file. The system should store the qualifier and the limit as separate fields, and the trending rules should define how censored values are handled. That handling is a statistical decision with real effect on slopes, so it belongs in a procedure, not in each analyst’s judgment.

Reportable Results Versus Individual Values

Dissolution, content uniformity, and many assays produce several individual values and one reportable result. Decide which the system stores, which it trends, and where the calculation from individual to reportable happens. If the calculation happens in an instrument data system or a separate calculation tool, the interface has to carry both, or the stability system cannot support an investigation.

Units, Rounding, and Precision

Store results at the precision reported by the method, with units as structured data, and apply rounding only for comparison to the specification, following your written rounding rule. Trending on rounded values can hide small, consistent changes that matter over a 36-month study.

Specification Linkage

Each study should point to the specification version in force for its purpose (registration, commitment, or ongoing), and the system should keep that link when a new specification version is approved. When a specification changes, the question “which studies are now evaluated against which limits” should have a single, queryable answer. That link is also where stability data connect to master data governance, which is its own discipline.

Protocols as Templates, Studies as Instances

One of the largest gains from a managed system comes from treating protocols as versioned templates. A protocol template defines conditions, time points, tests, and sample quantities. When a batch is placed on stability, the system creates a study from the approved template version, generates the pull schedule, and reserves sample inventory. When a protocol is amended, the amendment is a new version, and the system can show which studies it applies to and from which time point.

This design also makes the Chapter 6 annual batch requirement easier to show. If each commercial product has a defined ongoing protocol per strength and pack, the system can report, for any year, which combinations had a batch placed and which did not, along with the recorded reason if none was produced.⁵

Trending and Out-of-Trend Detection

Trending is the reason most companies make this move, and it is where expectations need the most care. A stability system can calculate regressions and flag results against limits. It cannot decide what counts as unusual for your products. That definition has to come from your statisticians and quality team, be written into a procedure, and then be configured.

Out-of-Trend Is Not Out-of-Specification

An out-of-specification (OOS) result fails an acceptance criterion. An out-of-trend (OOT) result is within specification but does not follow the expected pattern, either compared with other batches or with the earlier results of the same study. ISPE’s Pharmaceutical Engineering describes OOT results in these terms.¹³ OOS has a well-established investigation framework. OOT does not have a single harmonized regulatory procedure, although EU GMP Chapter 6 lists a procedure for investigating out-of-specification and out-of-trend results among the details that should be readily available to the Quality Control Department.⁵

Three Kinds of Alert

The most widely cited framework comes from the PhRMA CMC Statistics and Stability Expert Teams, published in Pharmaceutical Technology in 2005. It sorts OOT alerts into three types, in order of severity, with the depth of investigation increasing as the alert level rises:¹²

Choosing a Detection Method

Three statistical methods appear most often. The regression control chart fits a regression line to historical data and sets control limits around it along the length of the study. The by-time-point method calculates tolerance intervals at each time point from historical batches, without assuming a particular shape of degradation. The slope control chart compares the slope of a study with the distribution of slopes from historical studies.¹³ The PhRMA teams also describe four simpler methods that work best for analytical alerts: change from previous, change from previous per unit of time, change from initial, and the observed value itself, each with limits generated from a review of historical data. They describe these as better than an arbitrarily fixed, one-size-fits-all set of limits, which tends to be too narrow for some products and tests and too wide for others.¹²

Many spreadsheet-based programs use fixed rules of thumb instead, such as flagging a result that differs from the previous one by more than a set percentage. The ISPE article notes that these approaches are easy to understand and implement, but that their major disadvantage is a lack of statistical basis, which raises questions about how reliably they detect OOT results.¹³ Moving to a managed system is a good time to replace them, but it is not required to do both at once. A reasonable path is to configure your existing rules first, so that go-live changes only the tool, and then introduce statistically based limits product by product as your historical data allow.

The Historical Database Is the Hard Part

Every data-driven OOT method depends on a set of historical results that define “expected.” The PhRMA teams were direct about this: “The choice of which data are appropriate to include in this historical database is critical; it is probably as important as the choice of statistical method.”¹² They pointed out that the historical data must represent the future the limits will be applied to. If a process improvement changed the degradation rate, including batches from before it can produce limits that are too wide, too narrow, or centered in the wrong place, which leads to missed signals, false alarms, or both.¹²

This has two consequences for a system project. First, migration quality directly affects trending quality. A historical database built from migrated data with inconsistent units, missing actual pull dates, or unrecorded method changes will produce unreliable limits. Second, the rules for which batches belong in the historical set for each product need an owner and a review cycle. That is a quality and statistics decision, recorded in a procedure, with the system configured to apply it.

When Detection Happens

The PhRMA work recorded a clear wish from industry participants for simple approaches that allow real-time detection of OOT results at the bench, so that investigations can start quickly, especially when an analytical error is suspected.¹² This is where a managed system does something spreadsheets cannot do well. Analytical alerts can be checked the moment a result is entered, while the sample solutions still exist. Process control alerts, which need comparison across studies, may still be best reviewed on a schedule, and the PhRMA article notes they may be most easily detected during an annual product review.¹² A good configuration uses both: immediate checks for single results, and scheduled cross-study reviews for patterns.

Shelf-Life Evaluation Inside or Outside the System

Some stability systems perform Q1E regression and pooling tests themselves. Others export data to a validated statistical tool. Either can work. What matters is that the calculation follows Q1E (poolability at the 0.25 significance level, the appropriate one-sided or two-sided 95 percent confidence limit, and the extrapolation limits),² that it is validated for that use, and that the data it uses come straight from the system of record without manual reshaping. The worst outcome is a new stability system feeding a spreadsheet that someone uses to calculate shelf life, because that recreates the problem the project set out to fix.

Migrating Legacy Stability Data

Migration is where most stability system projects lose time. The data are old, inconsistent, and spread across files built by people who may have left. At the same time, the pull calendar does not pause for a project. The migration plan has to keep in-flight studies safe while moving history into a structure it was never recorded in.

Decide What to Migrate, and in What Form

Not every legacy study needs to become a fully structured record. A useful split is by what the data will be used for:

• Active studies need full structured migration, with every remaining pull scheduled in the new system. These are the studies where a gap causes a missed pull.
• Closed studies that feed trending for products still on the market need structured migration of results, dates, methods, and specifications, because they form the historical database for OOT limits and shelf-life evaluations.
• Closed studies for discontinued products or superseded formulations may be better archived as verified, read-only records with an index, rather than restructured at great effort for data no one will trend again.

Write these decisions down in a migration plan approved by quality. Retention obligations do not change because the data move. They apply to the archived records as much as to the migrated ones.

The Cleanup Work Nobody Budgets For

Mapping legacy stability data is rarely a simple column-to-field exercise. Expect to find and resolve:

• Time point labels written several ways, with actual pull dates missing for some studies
• Units that changed over time, or were implied rather than recorded
• “Less than LOQ” entries recorded as text, zero, or the limit value, with no note of which
• Results compared against specification limits that were typed into the workbook, with no record of which specification version they came from
• Method changes during a study that are recorded only in a comment or a separate change record
• Repeat and retest results where it is not clear from the file which value was reportable
• Studies that were stopped early without a recorded reason

Each of these needs a documented rule. Where the source does not contain the information, the migrated record should say so rather than fill the gap with an assumption. A migrated result with “actual pull date not recorded in source” is an honest record. A migrated result with a pull date inferred from the protocol schedule and presented as actual is not.

Verification That Holds Up

EU GMP Annex 11 states that if data are transferred to another data format or system, validation should include checks that data are not altered in value and/or meaning during the migration.¹⁴ The phrase “value and/or meaning” is the useful part for stability data. A result can arrive with the right number and the wrong meaning: attached to the wrong time point, compared with the wrong specification, or stripped of its “less than” qualifier.

A verification approach that covers both value and meaning usually has three layers:

1. Reconciliation counts. For every study migrated: number of time points, number of results, and number of results flagged OOS in the source, compared with the target. Counts catch dropped and duplicated records.
2. Field-level comparison. A documented, risk-based sample (or a full comparison where the data volume and risk justify it) of results checked field by field against the source, including qualifiers, units, dates, and specification links.
3. Recalculation of known answers. For products with a filed or approved shelf-life evaluation, rerun the regression on the migrated data and compare it with the evaluation on record. If the slopes, confidence limits, and conclusions match, the migrated data have kept their meaning for the purpose that matters most. If they do not match, the difference is a finding to investigate before go-live.

The third layer is specific to stability and is often skipped. It is also the check that most directly answers the question an inspector will ask: can the new system reproduce the conclusions the company has already filed?

Cutover for In-Flight Studies

Active studies need a cutover plan built around the pull calendar. Identify a cutover date. List every pull due in the weeks before and after it. Decide, study by study, whether the last pre-cutover result is entered in the old tool and migrated, or entered directly in the new system. Run a short period where the new system’s schedule is checked against the old tracker daily, so that any pull the migration missed is caught before it is late. Only retire the old tracker when those schedules have matched for an agreed period.

Plan for chambers too. If the new system tracks sample inventory by chamber and shelf, the physical inventory needs to be counted and reconciled against the migrated records at cutover. A mismatch found then is a small problem. A mismatch found when a 36-month pull turns up short of units is a much bigger one.

Validation That Fits the Risk

A stability data management system is a GxP computerized system. It holds records used to set expiration dates and storage conditions, and it supports decisions about marketed product. It needs to be validated for its intended use. The practical question is how to focus that effort where it protects product quality and data integrity, rather than spreading it evenly across every screen.

Start From Intended Use

Write the intended use in operational terms: the system schedules pulls from approved protocols, tracks sample inventory, records results, compares them with specifications, applies OOT rules, links to investigations, and produces data for shelf-life evaluation and annual product review. Then list the functions whose failure would affect a quality decision. For most stability programs those are:

• Generation of pull schedules from protocol versions, including amendments
• Comparison of results with the correct specification version
• OOT and OOS flagging logic and the limits it uses
• Any calculation the system performs, from reportable values to regression
• Audit trails, electronic signatures, and access control on results and protocol approval
• Interfaces that carry results from instruments or other systems

These are where scripted, documented testing belongs. Lower-risk functions, such as report layout or user interface preferences, can be covered by lighter, unscripted testing and vendor documentation, as a risk-based approach under GAMP 5 allows.

Test the Statistics Against Known Answers

If the system calculates regression, pooling, or OOT limits, test those calculations against independently calculated results. ICH Q1E includes worked examples of statistical approaches that can serve as a starting point,² but your own products’ data, with results independently calculated by a validated statistical tool, make better test cases. Include the awkward cases: censored values, missing time points, a single batch, batches that fail the poolability test, and an attribute that increases over time rather than decreasing.

Configuration Is Not a One-Time Event

A stability system changes constantly after go-live. New products, new protocol templates, new specification versions, new OOT limits, and new test methods are all configuration. Decide at the start which of those changes need formal change control and testing, and which are routine data entry under procedural control. A new protocol template for an existing product type might be routine with a second-person verification. A change to OOT rule logic is a validated-state change. Writing that split down before go-live prevents months of debate later.

A Practical Sequence for a Mid-Size Company

For a mid-size pharma or biotech company, the realistic constraint is people, not software. The same QC analysts, stability coordinators, and quality reviewers who run the program today will configure, test, and migrate it, while still meeting every pull. The sequence below is built around that constraint. It puts the decisions that are hard to change first and moves data in waves, so that no single cutover puts the whole program at risk.

Staffing the Work

Three roles decide whether this sequence works. A stability program owner in QC, who knows every study and owns the data conventions. A statistician, internal or contracted, who owns the trending rules and tests the calculations. And a quality reviewer with enough time allocated to review migration verification, not only sign it. Most delays in projects like this come from treating those three as part-time additions to full-time roles. If the company cannot free them, it is better to slow the waves than to compress review.

Where Outside Help Is Worth It

A mid-size company does not need a large implementation team, but it often benefits from outside help in three places: writing the data conventions (because the choices are easier to see from experience across several programs), designing the migration verification, and independent review of the statistical configuration. Configuration and testing can usually stay in-house, which also keeps the knowledge in-house after go-live.

What to Measure After Go-Live

A stability system is worth what it changes in the program. A small set of measures shows whether it is working, and each of them ties back to something regulators have cited.

Pull Timeliness

Percentage of pulls done within their window, reported weekly by product and site. This is the most basic measure and the easiest to get from a system that stores scheduled and actual dates.

Pull-to-Result Time

The time from pull to approved result, with the oldest open samples listed by name. This is the measure that would have shown the gap FDA described in the Glenmark letter, where testing was overdue by months and dissolution failures went unobserved for about 100 days after pull.⁹ FDA found the firm’s response inadequate in part because it did not give enough information on its stability load assessment, with pre-defined criteria, to evaluate whether resources were adequate, and asked for the assessment protocol, the report, and a CAPA assuring future resource adequacy.⁹ A managed system produces that evidence as a normal report.

Alert Volume and Closure

Number of OOT alerts raised, by type and product, and the time from alert to investigation start and closure. Very low volumes can mean limits are too wide. Very high volumes with most closed as “no assignable cause” can mean limits are too narrow, or that the historical database needs review.

Attribute Coverage

For each protocol, confirm the attributes tested match the attributes that can change during storage. A May 2026 FDA warning letter to Sato Pharmaceutical cited 21 CFR 211.166(a) where stability programs omitted quality attributes such as degradation products and dose uniformity for some products, and where chromatographic peaks that appeared during stability studies, not seen at release, were not identified or evaluated against acceptance criteria.¹⁰ A system cannot decide which attributes belong in a protocol, but a periodic review of protocol templates against product risk, run from the system, makes gaps easier to see.

Summary Currency

EU GMP Chapter 6 requires a written summary of all ongoing stability data, including interim conclusions, subject to periodic review.⁵ Measure how old each product’s summary is and whether it was produced from the system. A summary that can be regenerated at any time from current data is one of the clearest signs that the move off spreadsheets is complete.

Conclusion

Moving a stability program off spreadsheets is less about software than about structure. The regulations and guidelines already describe a structured record: protocols with time points and conditions, results evaluated against specifications, statistical evaluation of trends, and a quality system that notices when something changes. Spreadsheets can hold each of those pieces, but they struggle to hold the connections between them over years and across a portfolio. A stability data management system is worth the effort when it makes those connections explicit, keeps the pull calendar and the results in one place, and lets trends be seen when results arrive rather than once a year. The ICH Q1 revision, still a draft as of this writing and targeted for Step 4 in November 2026, points in the same direction by treating trend detection as a quality system capability.

The practical path for a mid-size company is to make the hard data decisions first, validate a narrow core, start new studies in the new system, migrate in waves with verification that checks meaning as well as values, and only then introduce statistical trending product by product. Sakara Digital works with pharma and biotech organizations on exactly this kind of move, from data conventions and migration design to validation planning. If you are weighing how to bring your stability program into a managed system and want an independent view on where to start, we are happy to have that conversation.

For Further Reading