ZoomRx · DevSecOps
Per-product infrastructure reports, measured against the ZoomRx Well Architected Framework — four themes, twenty-two measured practices. One report per product per cycle: what passed, what failed, and what happens next.
Products
What a report contains
The short version — whether the product is healthy, in plain terms.
Our strengths — what already holds, confirmed by the review.
Our risks — ranked by consequence, each with likelihood, impact and the cost of doing nothing.
Evidence — all twenty-two practices by theme, with measured values.
The standard
Our own definition of what good infrastructure looks like — four themes every product is expected to get right. Authored and maintained by the DevSecOps team, last revised 24 July 2026. The Well Architected Review turns it into twenty-two things that can be measured or inspected, and publishes each product's result as its State of Infra report.
4 themes · 10 design principles · 22 measured practices · 1 of 6 products reviewed
Why themes
Themes are the dimensions of a software application that DevSecOps is responsible for. Each is both a dimension of how a product must be built and operated, and a dimension of the team's contribution to every product at ZoomRx — security, reliability, cost and infrastructure.
A software application has multiple dimensions that need to be owned and driven with depth. Organising the work by theme means each one is treated consistently across all products — with clear practices, a reviewable standard, and an identifiable owner.
The four themes
How we use cloud resources efficiently to achieve business outcomes while keeping spending intentional and optimised. It covers budget governance and operational cost management — the practices that ensure every dollar spent on infrastructure is deliberate and justified.
Why it matters
Without spending discipline, costs grow silently and corrections become reactive.
Unchecked cloud spend erodes margins and creates financial opacity. This theme ensures spending is planned, tracked and continuously leaned out — freeing resources to reinvest in growth rather than waste.
Design principles
A budget sets a clear boundary we should not cross. It keeps us mindful and nudges us towards investing in infrastructure that adds more value.
What the framework asks for
Maintain a shared expense workbook tracking all cost-bearing components of the product and their costs.
Arrive at an annual budget for each product line based on their goals.
Commit to a variance goal — define the maximum acceptable deviation from budget and track actual spend against it monthly.
Operational expenses eat into the revenue of a product. Keeping them lean shrinks costs and opens up opportunities for reinvestment.
What the framework asks for
Leverage discounts provided by cloud platform providers such as savings plans and committed use discounts, and track them.
Optimise costs in lower environments by running or launching them only when required.
What the review measures
Trade-offs the framework acknowledges. Cold or scaled-down disaster-recovery environments need heavy tooling to bring up within the recovery target. Environments that launch on demand need investment up front. Optimising instead of adding capacity means spending time on benchmarking. And commitment-based discounts lock us to a vendor, which costs flexibility.
How we provision, manage and run infrastructure across ZoomRx. It sets the standards for how cloud resources are declared, what platforms workloads run on, and how infrastructure is tagged and documented — creating a foundation teams can operate with confidence and scale without friction.
Why it matters
When every team provisions differently, every system becomes a unique artefact that only its creator understands.
Inconsistent practices create cognitive overhead, configuration drift, and incidents that are hard to diagnose. Standardised infrastructure can be reasoned about, reviewed, and handed over without tribal knowledge.
Design principles
Establish a consistent, opinionated foundation for how infrastructure and workloads are run across the organisation. All cloud infrastructure must be managed as code — IaC is the approach and Pulumi is the tool. Every code repository runs static analysis as part of CI, and every container image is scanned before deployment. Configuration standards are versioned and every product must stay current.
What the framework asks for
Every product must maintain a system description document following the standard format.
All cloud infrastructure configuration and state should be managed using Pulumi.
Kubernetes is the primary approved platform for all application workloads. VM-based workloads are accepted where genuinely justified but must be tracked — and must not exceed 5% of total workloads.
All database workloads should run on Kubernetes or managed services.
Tag all infrastructure wherever tagging is supported. Mandatory tags per resource type are defined in the Tags Reference.
All code repositories must run SAST as part of CI, and all container images must undergo image and vulnerability scanning before deployment.
What the review measures
On VM exceptions. VM-based workloads are accepted where genuinely justified, but must be documented with a rationale. Undocumented VMs are findings; documented ones are accepted exceptions tracked toward the 5% ceiling. An absolute no-exceptions stance was rejected as unrealistic — it generated findings that could never be resolved.
How we ensure ZoomRx applications perform as intended and recover gracefully from failures. It covers incident response, disaster recovery and scaling — the practices that determine how well a system holds up under stress and how quickly it returns to normal when things go wrong.
Why it matters
Most failures are not unpredictable — they stem from the absence of a practised process.
Downtime and data loss affect user trust, revenue and team morale. This theme ensures that when things break, we are prepared to respond, recover and learn — consistently, across every system.
Design principles
Incidents are inevitable, whether caused by infrastructure failures, application errors or unexpected load. Detecting them early requires a status page capturing uptime and latency at the level of individual components and features, not just the landing page. Responding effectively requires a defined on-call process and a postmortem culture. Measuring the outcome requires a continuous view of product stability.
What the framework asks for
Every product must maintain a status page capturing uptime and latency at the level of individual components and user-facing features — not just the landing page. The format and implementation are left to each product.
Every product must maintain a stability index — a monthly report calculating product stability from HTTP status codes and response times, errors, and bugs.
Every application must have an on-call procedure with a designated team as first line of response, and a clear escalation matrix.
A disaster is a scenario where the system has suffered loss of data or critical configuration through manual error or systemic failure that cannot always be prevented. It is important to be prepared to restore the system to its original form — which requires a tested process that can be followed without hesitation when a disaster strikes.
What the framework asks for
Every application must have a disaster scenario document covering the ways each component can fail, the RTO and RPO target for each scenario, and recovery procedures — including backup strategy — mapped to meet those targets.
Conduct DR drills at a regular cadence, covering the scenarios in that document so different failure types are exercised. Drill reports must be stored centrally and available for audit.
Scaling decisions must be grounded in data, not assumptions. As the business grows, applications must scale to meet demand — but overprovisioning wastes resources and underprovisioning impacts reliability.
What the framework asks for
All scaling decisions must be driven by defined metrics and traffic estimates, not assumptions or blind overprovisioning, with dynamic scaling configured where supported.
What the review measures
Trade-offs the framework acknowledges. Reliability costs money — redundant infrastructure, imperfect capacity planning, and significant time from multiple teams. It adds operational complexity, since every additional component must be supported and understood. And during active incident response, urgency can create pressure to bypass security controls optimised for routine access.
How we safeguard ZoomRx applications and infrastructure from security attacks, vulnerabilities and unauthorised access. It covers data classification, identity and access management, network security, and workload hardening.
Why it matters
Protection has to be built in, not bolted on.
A single breach can compromise customer trust, expose sensitive data, create regulatory liability and disrupt business operations. Security is not a one-time configuration — it requires consistent practice across every system, environment and team.
Design principles
Before any security control can be applied effectively, the data being protected must be understood. Every product must identify and classify its data assets by sensitivity level. That classification drives decisions across identity, network and workload hardening — determining who can access what, what can be publicly exposed, and where the strongest controls are needed.
What the framework asks for
Every product must maintain a data classification document in the infra wiki listing all data assets and their sensitivity level.
Identity is the primary entry point into our systems for people. A robust framework — authentication, credential management, access control, and access lifecycle — is essential for keeping that entry point secure.
What the framework asks for
User authentication must be one of: Entra, GitHub, short-lived credentials under one day, password with MFA, or magic link.
All system credentials must be stored in HashiCorp Vault and rotated every three months.
Every product must have its RBAC or PBAC approach defined, with roles and policies for all systems configured according to that definition.
No terminated or reassigned user may retain access beyond 24 hours of the change.
Layer 4 and Layer 7 boundaries are the primary entry points for traffic into our systems. Strong network segmentation, firewall discipline and application-layer protections keep those boundaries defensible.
What the framework asks for
The network must be segmented into two zones — a DMZ that is public-facing and contains only proxy and WAF components, and a militarised zone that is private and contains application and database workloads. No component in the militarised zone should be directly reachable from outside the VPC; all inbound traffic must enter through the DMZ proxy.
Databases must not expose their native port to the public internet. Where external query access is required it must be routed through an authenticated proxy.
Apply least privilege to firewall rules. Use specific CIDR blocks; 0.0.0.0/0 is permitted only on the DMZ proxy and only on ports 80 and 443. Overly broad internal ranges are not permitted.
All web application endpoints should have DDoS protection and a WAF enabled.
Workload hardening reduces attack surface by keeping the software we run — operating systems, containers and dependencies — current with vendor security patches. Security gaps are often invisible until a breach occurs; there is no outage, no cost spike, no immediate signal that something is wrong. That makes proactive hardening essential.
What the framework asks for
All software components — operating systems, container base images and application dependencies — must be kept current with vendor security patches across all environments.
What the review measures
How adherence is verified is not part of this framework. Static analysis, vulnerability assessment, penetration testing and continuous scanning are defined in the Well Architected Review, not here. SOC 2 certification and independent penetration testing were standalone requirements until the framework was revised in July 2026 — penetration testing now feeds Network protection as an input, and SOC 2 has no practice of its own.
How it works
Each theme sets out recommendations drawn from experience and industry practice. The review turns those into twenty-two things that can be measured or inspected, and runs them against a product. Seventeen are collected automatically from our cloud platform, code repositories and internal systems; four are a human reading a document; one comes from a dashboard.
The output is a State of Infra report per product per cycle — a health verdict, the risks worth attention, the decisions needed from product and leadership, and the evidence behind all three. Gaps are findings with a next step, not failures.
Glossary
ZoomRx · DevSecOps
The short version
Over the 91 days of this period there was no customer-affecting outage, data stayed protected and recoverable, and our SOC 2 certification remains current. The concerns are of a different kind: spend has closed above budget every month since April and is still rising, and the first full measurement against the company standard found twelve of twenty-two practices not yet established — mostly things never set up rather than things going wrong. Most of them are ours to close before the next run. With FY26 in its final quarter, this is not a mid-year correction; it is the evidence base for the FY27 budget, which is being set now.
Second
What already holds — confirmed by this review rather than assumed. The gaps further down sit on this foundation.
No customer-affecting outage across the whole period. When an alert is real, the response is prompt — about 20 minutes; the poor headline response numbers are an artefact of alert noise, not of the response.
Recovery targets are declared — two hours to recover, five minutes of acceptable data loss — and the January 2026 exercise came in at 50 minutes and 5 minutes, comfortably inside both.
Customers sign in with one-time email links, staff with company accounts, and services authenticate as themselves rather than holding keys. Nothing shares a password.
SOC 2 Type 2 is current for Ferma Agents — the independent security certification customers ask us for.
97.6% of production workloads run on the approved platform, and every production database is a managed service with regional failover behind it.
70% of in-scope infrastructure is managed as code overall, and lower environments are at 91% — everything the automation is meant to manage there is under it. Bringing production under the same automation is the open piece.
A shared expense workbook with Finance and a monthly variance check against a committed budget. The current trend is the concern; the tracking that caught it is the strength.
Where the strength sits, by theme
The most complete theme. The workbook, budget tracking and commitment discipline all hold; the one gap is a missing lower-environment ceiling.
Strong where it counts — uptime held and recovery is proven. The gaps are process, not runtime: no on-call structure, no stability index.
The platform foundation is right — approved platforms, fully managed production databases. The gaps are in how it is managed: production sits outside automation, tagging and scanning lag.
The thinnest theme. Identity is genuinely strong, but every other layer runs on a single control or none — traffic filtering, scanning and independent assurance are all absent.
Third
Ranked by consequence. Likelihood and impact are our assessment, not a measurement. Open a risk for the detail and the cost of doing nothing — which is itself a choice.
The −0.2% annual variance is an average that masks six months of overspend. With two months left in the fiscal year, FY26 will land at roughly $360–400k against a $267k budget whatever we do now. The decision left is not FY26 — it is whether FY27 is planned against the real run rate or against last year's number.
FY27 gets budgeted from a $267k baseline that has already been overtaken, and we spend next year repeating this conversation every month.
Our existing web application firewall was deliberately not applied here — it would cut off any request running longer than 100 seconds, which Ferma Agents routinely exceeds. That exclusion was the right call, but it leaves the portal with nothing filtering traffic in front of it.
Our main entry points stay unprotected against exactly the traffic a filter exists to stop.
There is no documented on-call process for Ferma Agents — no escalation path, no rota, and no second line. Coverage currently depends on individual availability rather than an agreed rotation. The results over this period were strong — 264 alerts handled and no customer-facing outage. The concern is not how it has gone; it is that there is no structure to fall back on.
A serious incident arriving outside Karthick's availability has no defined path to follow. It is also why incidents are not written up afterwards — informal coverage offers no natural point at which that happens, which is how the recurring capacity issue in the alert-noise risk below went unremarked. Defining the process is ours; extending coverage is a resourcing question.
Third-party libraries are covered — Dependabot alerts are enabled and flag known-vulnerable dependencies as they are published. Beyond that, three checks are absent: static analysis of the code we write ourselves, scanning of container images before they are deployed, and continuous scanning of what is already running. There has also been no independent test within the last year.
Code we write ourselves, and the images we ship it in, reach production unchecked — so a flaw in our own work surfaces through an audit or an incident rather than through us. Our SOC 2 posture also expects periodic independent testing.
Of 264 alerts, about 55% clear themselves within five minutes and nobody acts on them. Disk capacity alone is one alert in five and has recurred for months — the pattern only became visible once the alerts were reviewed together.
The next genuine incident is spotted late because it looks like the other 144. This is the one risk with demonstrated harm already.
The rule permitting remote login from anywhere is not tied to specific machines, so it applies across the whole network. Only one machine currently runs, so today's exposure is a single server.
Any new machine inherits the exposure automatically, without anyone deciding to. Scoping the rule is a small change — DevSecOps owns it, no decision needed from you.
The question we cannot answer yet
If you asked us today whether Ferma Agents will hold when content volume doubles, we could not tell you. The platform scales itself and has never fallen over — but we do not currently measure how much headroom is left, and the thresholds that govern scaling have never been written down with a reason attached. That measurement is the single most useful thing we could add before the next run, and it is also the main lever on the cost trend in the spend risk above.
The backing detail
Everything above, traced to the company's infrastructure standard — 22 practices across four themes. Read this only if you want to check our working. Scope differs by theme by design: infrastructure and cost are measured across production and lower environments; security and reliability cover production only. What the standard actually asks for is on each theme page — FinOps, InfraOps, Reliability, InfoSec.
Where Ferma Agents stands against the 22 practices
All twenty-two practices are measured — nothing is left unknown. This is the baseline. The next run, on 5 November 2026, will show direction: which numbers moved and which findings closed. Click a theme name to open its evidence below.
Where the spend went over
Every month from October to March came in under budget, between 28% and 64% below it — which is what holds the annual average down. Individual figures for those months were not captured; the workbook records only the range. April is where the direction changed, and it has not changed back. The drivers are LLM providers and Google Cloud — cost that rises with the volume of content the product processes.
Practice status
The infra wiki links to the FY26 Software workbook, Ferma Agent tab — the shared record Finance and engineering both work from.
Measured monthly against a committed budget, with a stated goal. What the number now shows is the spend risk above.
Ferma holds no commitments of its own and draws on ZoomRx's shared pool, so coverage is managed at company level rather than per product. There is no Ferma-attributable figure to report here.
No ceiling is set, and the reason is worth stating. Our sourcing and extraction pipelines run in the lower environments, so spend there is not development or test consumption — it is the cost of the product doing its job. The open item is cost attribution rather than a limit: until product cost can be told apart from development cost, there is nothing meaningful to set a threshold against.
July closes after this draft — its actuals load in the first week of August and are included at publication.
What those 264 alerts actually are
Grey is noise. When an alert is real the response is prompt — about 20 minutes — so the poor headline numbers are an artefact of the population, not of the response.
Practice status
health.ferma.ai is live and publishes uptime from 24 hours to 90 days with an incident history. But it reports one overall status and no response times, so it cannot tell you which part is degraded, or that something is slow rather than down.
Not established. The measure combines response codes and times, application errors and bug counts. 100% uptime does not evidence it — a product can be entirely available and still slow and erroring.
No documented process — no escalation path, no rota, no second line. Coverage depends on individual availability. The incident-response risk above.
Targets are declared — 2 hours to recover, 5 minutes of acceptable data loss — and the last exercise, in January 2026, came in at 50 minutes and 5 minutes, comfortably inside both. It covered database recovery from backup; extending the same treatment to other failure modes is the next step.
Thresholds are version-controlled, but carry no stated rationale and no utilisation measure.
The finding here is production, not the percentages. Lower environments are at 91% — everything our automation is meant to manage has been brought under it, and the only gap is two container registries. Production is at 0% because it was never brought under automation at all. Its infrastructure is changed by hand, so there is no record of what was changed, no review before it happens, and no way to rebuild it from a definition. That is the gap worth closing.
Lower environments fail the platform target on their own — 94.2% against a 95% floor — and pass only when production's larger workload count is averaged in. Every database still on a machine sits in a lower environment; production runs 100% of its databases on managed services. The system description document covers production; lower environments are not described.
What is counted. Infrastructure our automation is designed to manage: storage buckets, databases, clusters and container registries. Excluded: virtual machines and message queues (out of scope by design), load balancers the cluster creates for itself, our automation's own state storage, build-system scratch space, and everything belonging to the retired chat service. Tagging is measured over a wider set — see that row's own note.
Defence in depth — outermost layer first
The live portal has no web application firewall and no DDoS protection. Our existing filter was deliberately not applied — it would sever requests over 100 seconds, which Ferma Agents routinely exceeds — but no alternative has been assessed. The WAF risk above.
GapRemote administrative accessOpen from anywhere, and the rule is not tied to specific machines, so any new machine inherits it. One machine is currently reachable. The remote-access risk above.
In placeNetwork zoningPublic-facing and private components sit in distinct zones exactly as intended, with a standby region behind them. The database's public address is a documented accepted risk — required, with no external source authorised to use it.
GapIndependent assuranceNeither check this layer expects has been run — no continuous scanner and no external penetration test within the last year. The scanning risk above.
Customers use one-time email links, staff use company accounts, and services authenticate as themselves rather than sharing credentials. Two internal tools sit outside the standard as recorded exceptions, credentials held centrally.
PartialCredential handlingNothing rotates on a schedule, but the architecture removes most of the need — services hold no keys, and staff app credentials carry a mandatory expiry. Residual secrets held centrally have neither. The rationale is sound but unwritten, and an unwritten exception counts as a gap.
GapWho can reach whatRoles are properly separated in practice, but the intended access model has never been written down, so there is nothing to check the live configuration against. Measured this run: eleven people hold direct production access, four of them unrestricted, and none is managed through a group.
GapAccess removal when someone leavesNo defined process — handled as it arises, with no record. Made harder by access being granted person by person, so removal means finding each grant by hand.
Third-party libraries are checked against published vulnerabilities as they are disclosed.
GapStatic analysis and image scanningNeither is in place. The code we write is not analysed for flaws, and container images are not scanned before deployment — scanning is switched off on all four repositories. The scanning risk above.
GapKeeping software patchedNo patch management process exists. Twelve of thirteen production machines have no patch group assigned.
Connections to the database are encrypted, the database tier sits in the private zone, and recovery is regional with point-in-time restore.
GapKnowing what data we holdThe company classification policy exists and is thorough, but no one has listed Ferma's own data assets against it. Drafted and awaiting sign-off.
Read the layers, not the count. Identity is the only one with more than one working control — everywhere else a single measure is doing the job alone, or nothing is. The perimeter is thinnest: filtering absent, administrative access open, and neither independent check performed. Nothing here is broken; most of it was never set up.
Also true, and outside the layers: SOC 2 Type 2 is current for Ferma Agents through January 2026. It stopped being a practice in its own right when the standard was revised in July 2026, and is recorded here because it still matters.
Appendix
The framework itself — what each theme asks for and how every practice is measured — is described on its own page: FinOps · InfraOps · Reliability · InfoSec.