Products in fintech, healthcare, and other regulated sectors cannot ship on the same cadence as a consumer app, but that does not mean they should default to quarterly feature freezes either. The right answer is a hybrid: continuous integration and automated testing run every day, while the actual production release is gated behind a formal change-approval checkpoint tied to the regulator's sign-off window. Teams that treat "regulated" as a reason to freeze everything for months typically end up with larger, riskier releases, not safer ones. Teams that structure their pipeline correctly can keep daily integration cycles while still satisfying auditors who want documented, pre-approved changes before anything touches production.
This distinction matters because the two release models solve different problems. Continuous delivery keeps software in a permanently releasable state and uses a human approval step before production, while continuous deployment removes that step entirely and ships every change that passes its tests. Feature freeze is neither of these; it is a scheduling decision that stops new code from entering a release branch for a fixed window, usually to stabilize a build ahead of a compliance milestone. Understanding where each mechanism sits in the pipeline is the first step to designing a cadence that survives an audit.
TL;DR
Continuous delivery and feature freeze are not opposites; regulated products typically combine continuous integration with a gated, pre-scheduled release step.
ISO 27001 Control 8.32 and ISO 9001 both require documented change management before implementation, but neither standard mandates a specific release frequency, which leaves cadence design up to the engineering team.
Low-performing teams that rely on feature freezes deploy once a month to once every six months; elite performers using continuous delivery deploy on demand, multiple times a day, according to DORA's State of DevOps research.
Feature flags and progressive delivery let teams decouple "code merged" from "feature visible," which is the mechanism that makes frequent deployment compatible with a fixed regulatory approval date.
Vietnam-based delivery teams working across timezones need a release calendar with explicit ownership at each checkpoint, not just a shared document listing dates.
About the Author: 724SOFTWARE is a Vietnam-based engineering partner that has built and operated regulated platforms for clients including SHS Derivatives (millisecond-level trade execution under a real-time risk engine) and MyVIB Stock Trading (in-app securities trading inside a live banking app with eKYC onboarding), giving the team direct experience structuring release pipelines around compliance sign-off rather than around theory.
What Is the Actual Difference Between Feature Freeze and Continuous Delivery?
A feature freeze is a defined period during which no new functionality is merged into the release branch, used to stabilize a build before a milestone. Continuous delivery is an engineering practice that keeps the software in a releasable state at all times, with automated testing running on every change and a human decision gating the final push to production.
The two are not mutually exclusive: a team can run continuous integration and automated testing every day of the year and still freeze the release branch for the two weeks before a regulatory submission.
The confusion usually comes from treating "continuous" as meaning "constantly shipped to users." It does not. Continuous integration is the practice of merging code frequently and validating it automatically; continuous delivery adds the guarantee that any validated build could be released on demand. Continuous deployment is the further step of removing the human approval gate and shipping every passing build automatically. A regulated fintech or healthcare product almost never wants continuous deployment in production, because a human sign-off step is exactly what the regulator is asking for. But it can, and should, want continuous delivery internally, so that when the sign-off window opens, the release is a formality rather than a scramble.
Why Do Regulatory Sign-Off Windows Force a Different Release Model?
A sign-off window is a fixed date, set by an external body, before which a specific build must be frozen, documented, and submitted for approval. This is a hard external constraint, not a technical one, which means the engineering pipeline has to bend around a calendar it does not control. ISO 27001 Control 8.32 requires that changes to information systems be formally planned, assessed, authorized, tested, and documented before implementation. ISO 9001 imposes a similarly structured change management framework to evaluate risk and verify quality. Neither standard specifies how often a team may release; they specify that whatever cadence is chosen must be documented and auditable.
That distinction is the one most teams miss. Compliance does not require infrequent releases. It requires traceable ones. A team that deploys three times a week with a documented approval record for each deploy is in a stronger audit position than a team that deploys twice a year with informal sign-off. The mechanism worth understanding here is similar to a building inspector reviewing renovation work: the inspector does not care whether each structural change was permitted, inspected, and logged before the next one started. Release cadence is the renovation schedule; the audit trail is the permit file.
How Should a Release Calendar Be Structured Around a Fixed Sign-Off Date?
A release calendar for a regulated product needs three distinct phases: an open integration window, a stabilization window, and a locked submission window, each with a named owner. In the open window, engineers merge daily against automated test suites, exactly as they would on a non-regulated product. In the stabilization window, typically two to four weeks before the sign-off date, new feature merges stop but bug fixes continue under a stricter review process. In the locked window, the exact build submitted for regulatory review is tagged, and nothing changes in it until approval is granted.
Phase | Duration | What changes | Who owns the gate
|
|---|---|---|---|
Open integration | Ongoing | Feature merges, daily automated testing | Engineering lead |
Stabilization | 2-4 weeks pre-submission | Bug fixes only, regression testing | QA lead |
Locked submission | Until sign-off received | No code changes to submitted build | Compliance / release manager |
Feature flags are the tool that makes this workable without slowing the team down. A flag lets a team merge and test a feature in production-adjacent environments while keeping it invisible to end users until the flag is flipped, which decouples the engineering timeline from the release timeline. Deployment strategies such as canary releases or blue-green rollouts add a further layer of control, letting a team validate a change against a small slice of traffic before it reaches every user, which matters when a regression could affect a production trading engine or a patient record system.
What Happens When Teams Default to Long Feature Freezes Instead?
Building on the calendar structure above, the risk of skipping it is concrete rather than theoretical. According to DORA's State of DevOps research, low-performing teams that rely on long feature freezes and infrequent releases typically deploy once a month to once every six months. Elite performers using continuous delivery deploy on demand, multiple times a day, with lead times under a day. The gap is not just speed; it is risk concentration. A team that batches six months of changes into a single release is shipping six months of untested interaction effects at once, which is precisely the failure mode regulators are trying to prevent by requiring change documentation in the first place.
A related but distinct question is why teams keep defaulting to long freezes anyway. In most cases it is not a technical decision but a trust gap: without automated testing and a documented approval trail, a long freeze feels like the only way to guarantee stability before an audit. Building the automation and the audit trail is the actual fix, not extending the freeze window further.
How Does a Vietnam-Based Delivery Team Handle This Across Timezones?
Extending release governance across a distributed team adds a coordination layer, but it does not change the underlying mechanics. What it requires is explicit ownership at each checkpoint and a working-hours overlap that lets the compliance-side team reach engineering when a question comes up during the locked submission window. 724SOFTWARE runs a follow-the-sun delivery model with a guaranteed incident response time under 10 minutes, which is built for exactly this scenario: a question raised by a client's compliance team at 9am Sydney time needs an engineering response before the submission deadline, not the next business day in a single timezone.
This is also where alignment with ISO 27001:2022 and ISO 9001 standards matters operationally rather than as a checkbox. Formal change documentation is not something bolted onto a release at the end; it has to be generated as part of the normal pull request and deployment workflow, which is why teams that have built regulated platforms before (trading systems with millisecond-level execution requirements, in-app banking integrations with eKYC onboarding) tend to have the audit trail built into their CI pipeline rather than reconstructed after the fact.
Frequently Asked Questions
Does continuous delivery mean releasing to production without approval?
No. Continuous delivery keeps a human approval step before production; continuous deployment is the model that removes it and ships every passing change automatically.
Can a regulated product ever use continuous deployment?
Rarely for the customer-facing production environment, because most regulators expect a documented human sign-off before release. Continuous deployment is more common inside staging or pre-production environments that feed into the locked submission build.
How long should a stabilization window be before a sign-off date?
It depends on the complexity of the release and the regulator's review process; two to four weeks is a common range, but the exact figure should be set based on defect rates observed in the team's own historical releases.
Do ISO 27001 or ISO 9001 require a minimum release frequency?
No. Both standards require documented, risk-assessed change management before implementation, but neither specifies how often releases must happen.
What is the biggest mistake teams make with feature freezes?
Treating the freeze as a substitute for automated testing and change documentation, rather than as a scheduling tool layered on top of them.
How does an offshore Vietnam IT company handle sign-off windows across timezones?
By assigning a named owner to each phase of the release calendar and maintaining working-hours overlap with the client's compliance team, so questions raised during the locked submission window get an engineering answer within the same business day.
About 724SOFTWARE
724SOFTWARE is a Vietnam IT company with 200+ engineering professionals, 58% of whom are senior-level, delivering software across 10+ countries with domain depth in Fintech, Digital Healthcare, and Enterprise ERP. The company has built and operated regulated production platforms, including derivatives trading systems with millisecond-level execution and in-app banking integrations with eKYC onboarding, where release governance and audit documentation were part of the delivery scope from day one.
As an offshore software development Vietnam partner, 724SOFTWARE runs a follow-the-sun support model with sub-10-minute incident response and aligns its delivery practices with ISO 27001:2022 and ISO 9001 standards, which matters directly to any client managing a fixed regulatory sign-off date. Teams can scale from 1 to 50+ pre-vetted engineers within 2-4 weeks, giving clients the flexibility to staff up ahead of a compliance milestone without rebuilding a delivery process from scratch.
If your product is approaching a regulatory sign-off window and your release process still relies on a long feature freeze, it is worth reviewing where automated testing and documented change approval could replace the freeze with a structured, audited cadence instead. Get in touch with 724SOFTWARE to talk through how a dedicated team can be structured around your compliance calendar.
