ARCH-5 Tech Due Diligence

Tech Due Diligence ARCH-5: Technology Stack Currency and Fitness

What This Control Requires

The assessor evaluates whether the technology stack (languages, frameworks, databases, infrastructure) is current, well-supported, and appropriate for the problem domain, including the availability of talent and community support.

In Plain Language

Your technology choices have long-term consequences for hiring, maintenance costs, security posture, and development velocity. An outdated stack means expensive upgrades, mounting security risks, and a shrinking talent pool. An overly exotic one means you struggle to hire and onboard new developers.

Assessors review the primary programming languages and their versions, web frameworks and their release status (current, LTS, or end-of-life), database technologies and their fit for the data model, infrastructure platforms, and supporting tools like message queues, caching, and search. For each technology, they consider whether it is actively maintained, whether the version in use still receives security patches, and whether there are enough developers on the market to support the company's hiring needs.

Technologies past end-of-life are a significant risk flag because they no longer get security patches, community support dries up, and hiring gets progressively harder. On the other hand, being on the absolute bleeding edge can be equally risky if the technology is immature or the talent pool is tiny.

How to Implement

Maintain a clear inventory of all technologies running in production. Cover language and runtime versions, framework versions, database versions, infrastructure platform details, and significant third-party services. For each one, track the version in use, latest stable version available, end-of-life dates, and upgrade path complexity.

Keep everything within supported versions. As a rule of thumb, languages and runtimes should be within one or two major versions of current, frameworks should be on the current or previous LTS release, databases should be receiving security patches, and operating systems should be actively supported.

Plan technology upgrades proactively rather than waiting for things to break. Create an upgrade calendar that tracks EOL dates and schedules upgrades well in advance. Major version jumps (Node.js 18 to 20, Python 3.10 to 3.12, etc.) should be planned as dedicated projects, not left until the old version loses support.

Evaluate whether each technology fits the problem domain. Assessors look for appropriate database technology for the data model, language choices that match the domain (strong typing for financial systems, rapid development for early-stage products), and infrastructure that suits the deployment model.

Consider the talent market for your stack. Can you hire developers with these skills in your market? Are salaries sustainable? Is the technology popular enough to attract candidates? Technically superior but niche technologies create real hiring risk that assessors will flag.

Document any planned migrations or major upgrades. If you are moving from one technology to another, write down the rationale, migration plan, timeline, and risks.

Evidence Your Auditor Will Request

Technology stack inventory with versions and EOL dates
Technology upgrade calendar and recent upgrade history
Justification for technology choices relative to problem domain
Hiring market assessment for key technology skills
Planned technology migration documentation (if applicable)

Common Mistakes

Core technologies past end-of-life with no upgrade plan
Technology choices driven by developer preference rather than business suitability
Niche technology stack that severely limits the hiring pool
Multiple languages and frameworks used without clear justification, increasing complexity
Framework upgrade deferred for years, creating a large and risky upgrade project

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.8.8	Related

Frequently Asked Questions

Is using a less popular technology a red flag?

It depends entirely on context. Erlang/Elixir for a real-time communication system or Rust for a performance-critical component shows good engineering judgement. Using an obscure language for a standard web application without clear justification raises legitimate concerns about hiring and long-term maintainability.

How far behind current versions is acceptable?

Being one major version behind is generally fine as long as you have an upgrade plan in place. Two or more major versions behind is a yellow flag. Running on a version that has reached end-of-life and no longer receives security patches is a red flag that needs immediate attention.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment