The question arrives in almost exactly these words: "can one person really handle cloud, devops and security for a startup or do we need three hires". It is usually asked by a founder or a first engineering lead who has just priced three job descriptions and did not like the total. It is a budget question wearing an org-design costume.
Most answers online fail in one of two directions. Vendors answer "yes, obviously" and attach a pricing page. Hiring content answers "no, these are three distinct disciplines" and attaches three job descriptions. Neither tells you where the line sits: what genuinely compresses into one person, and what stops being possible no matter how good that person is.
This post draws that line. Five duties compress into one competent generalist. Three do not, and the reason they do not is structural rather than a question of skill or effort: a 24/7 rotation needs bodies, a control that requires two roles cannot be performed by one, and an independent test cannot be run by the person who built the thing. Where I am giving a practitioner read rather than citing a document, I have labelled it inline.
Quick context: three job families, one budget line
In 2026 the work a startup calls "cloud, DevOps and security" is three job families that overlap heavily at small scale and diverge sharply at large scale. Cloud or platform engineering owns account structure, networking and the infrastructure definition. DevOps or SRE owns the delivery path and the reliability of what is running. Security owns identity, exposure, detection and the evidence an auditor or customer asks for.
At 50 engineers these are three teams with separate rotations and separate managers. At eight engineers they are mostly the same forty hours of work a month, done by whoever is least afraid of the AWS console. Which of those two you are in decides the answer, and the useful version of the answer names the tests that tell you.
Can one person really handle cloud, devops and security for a startup or do we need three hires?
Yes, one competent generalist can own cloud, DevOps and security for a startup under roughly 15 engineers on a single production environment. One person covers the daily run: infrastructure as code, the CI/CD pipeline, baseline hardening, identity and access, and cost control. Three duties need a second person however good that one person is: continuous out-of-hours cover, any control requiring separated roles, and independent testing. Those three are structural, not effort.
That is the whole answer, and the rest of this post is the evidence for each half. The first half matters because three hires at this stage is usually the more expensive mistake. The second matters more: it is the half vendors leave out, and the half that fails your first audit.
1. What the three roles actually own
The hiring question is unanswerable until the work is named, and the division of labour with your provider is published: under the AWS shared responsibility model, the provider owns security of the cloud and you own security in the cloud. Everything on your side of that line is what you are staffing.
The AWS Well-Architected security pillar breaks your side into seven areas: security foundations, identity and access management, detection, infrastructure protection, data protection, incident response, and application security. Read it as a staffing document rather than an architecture document. Six of the seven are design-and-build work on a schedule you control. One, incident response, runs on someone else's clock.
Takeaway: write your own version of that seven-area list before the job description. Build work sequences into one person. Response work does not, and that split answers the headcount question.
2. What genuinely compresses into one person
Five duties compress well, because each is built once and then maintained, not watched.
- Infrastructure as code. A single engineer can define a whole small estate in Terraform and keep it reviewable. HashiCorp's remote state documentation exists because the hard part is shared state and locking, which is a one-time decision rather than ongoing load.
- The CI/CD pipeline. Build, test, scan and deploy is configuration work. Pinned and documented, it runs without a human in the path.
- Baseline hardening. The CIS Benchmarks are published and prescriptive. Applying one is a finite project, not a standing team.
- Identity and access. Least privilege at small scale is a few dozen roles. IAM Access Analyzer generates policies from observed activity and reports external access, which is the leverage that lets one person hold identity here.
- Cost control. Tagging, budgets, rightsizing and commitments are a monthly review, not a daily duty.
The common property is that all five are automatable and schedulable. That is not an accident of the list: it is the definition of work that compresses.
Takeaway: if a duty is expressible as code, a benchmark or a monthly review, one person can own it at your size. Stop counting those duties when you count heads.
3. The first hard limit: a rotation needs bodies, not effort
This is the limit no amount of seniority solves, and it has a published number attached. Google's Site Reliability Engineering book, chapter 11 works out minimum staffing for a sustainable rotation: assuming a primary and a secondary always on call and week-long shifts, the minimum is 8 engineers for one rotation at a single site, or six per site across two sites.
That number falls out of a workload cap: the chapter on eliminating toil states Google's goal of keeping operational work below 50% of each engineer's time. Cap how much of a month can go to on call and the arithmetic decides the headcount for you.
Your startup is not Google and does not need Google's rotation. What transfers is the direction of the constraint. If you need somebody awake and accountable at 02:00 every night, one person cannot supply it, and neither can three: three hires is a three-person rotation, one week in three on call, indefinitely. Practitioner opinion: that is a resignation generator.
Takeaway: decide what you need out of hours before counting heads. "Production down gets a human at any hour" and "every alert gets a human at any hour" are different products, and only the first is affordable here.
4. The second hard limit: separation of duties
The second limit is a control-design limit, where a single-owner setup fails an audit rather than a server.
If you touch card data, PCI DSS v4.0 is explicit. Requirement 6.5.3 requires pre-production environments to be separated from production, enforced by access controls. Requirement 6.5.4 requires roles and functions separated between production and pre-production so that only reviewed and approved changes are deployed. One person who writes, approves and deploys the change does not satisfy 6.5.4, and no amount of care makes that control design pass. Text in the PCI SSC document library.
SOC 2 is softer and lands in a similar place. The AICPA Trust Services Criteria criterion CC6.3 asks the entity to authorize, modify or remove access based on roles and responsibilities, giving consideration to least privilege and segregation of duties. "Giving consideration to" is not "must have three people", which is why small companies do pass SOC 2 with one administrator. They pass on compensating controls: someone other than the administrator reviews privileged activity, privileged changes carry a recorded approval, and access reviews run on a documented cadence.
Takeaway: if you have one infrastructure owner, your second person for this purpose does not have to be another infrastructure engineer. It has to be a different human with a review duty and a record. Practitioner opinion: the CTO or the engineering lead reviewing a monthly privileged-activity report is the cheapest version of this control that an auditor will accept.
5. The third hard limit: independent testing
The third limit is the shortest to state. The person who built the system cannot be the person who independently tests it.
PCI DSS requirement 11.4 is the clearest published statement of this. Its penetration testing requirements call for a qualified internal resource or qualified external third party, with organizational independence of the tester, and note the tester need not be a QSA or an ASV. Independence, not certification, is the hurdle: the tester must not control the systems being tested, which rules out your one infrastructure owner by definition.
This one has a clean commercial answer and needs no hire. Practitioner opinion: for a seed-stage company, buying independence two to four times a year is cheaper and more credible than building it, because an external report is also the artefact your enterprise customer asked for.
Takeaway: never count independent testing as a reason to hire. It is an annual budget line, and the report is the questionnaire artefact.
6. The regulatory clock: 6 hours to report
If you operate in India, an external clock makes the out-of-hours question concrete. CERT-In's directions under section 70B(6) of the Information Technology Act, 2000 (Direction No. 20(3)/2022-CERT-In, dated 28 April 2022, effective 27 June 2022) require covered entities to report cyber incidents within 6 hours of noticing them or being brought to notice. The obligation is broad, naming service providers, intermediaries, data centres, body corporates and government organisations. Published by CERT-In.
Read that against a single owner on annual leave. The clock does not pause, and six hours is shorter than one working day. That is not an argument for three hires. It is an argument for a named deputy and a written procedure, which is a far smaller purchase than a headcount.
Takeaway: write the reporting runbook while nothing is broken, name a non-engineer who can start the clock, rehearse it once. One person plus a rehearsed deputy beats three people with no runbook.
7. Who should own cloud infrastructure and security at a 10 person startup?
At 10 people, one named senior owner should hold cloud infrastructure and security, and the founder or CTO should hold the review duty over that owner. Splitting ownership across a 10 person team gives you the worst outcome available: shared responsibility with no accountable name. The owner can be a full-time generalist, a fractional senior, or the technical founder, and the deciding factor is hours a month, not title.
Practitioner opinion: track the hours for one month before deciding. At a 10 person startup with a single production environment the load is usually 20 to 40 hours a month once the initial build is done. Under 20, a full-time hire spends most of the month looking for work, which is how good infrastructure engineers end up writing features and then leaving.
Takeaway: one accountable name, one reviewer, one measured hours figure. Those three answer the staffing question better than any job description.
8. The arithmetic: three hires against one hire against a retainer
Three hires against one person is a cost comparison, so here are published numbers rather than a gesture at them. All three are national averages for base salary in India, with sample size and date, and none is a senior-at-a-product-company figure.
| Role | Published average base, India | Source, sample and date |
|---|
| DevOps engineer | ₹8,29,500 (typical ₹5.15 L to ₹13.72 L) | Glassdoor, 15,109 submissions, July 2026 |
| Cloud security engineer | ₹10,90,000 (typical ₹6.09 L to ₹16.07 L) | Glassdoor, 129 submissions, June 2026 |
| Site reliability engineer | ₹13,05,177 | Indeed, 31 submissions, September 2026 |
Those averages add up to about ₹32.2 lakh of base salary a year. Fully loaded cost is higher: employer contributions, equity, hardware, tooling seats, recruiter fees. Practitioner range, labelled as such, is 1.25x to 1.5x base, putting three mid-level hires near ₹40 lakh to ₹48 lakh a year. Three genuinely senior hires sit well above that, which is why our own published comparison uses ₹1.8 crore to ₹2.4 crore a year. Both numbers are real, the gap between them is seniority, and you should settle which band you are hiring in before comparing anything.
Against that, our published retainer rates are ₹30,000 a month ($2,500) for up to 20 hours, ₹1,00,000 ($5,000) for up to 40, and ₹2,50,000 ($10,000) for up to 80, with production-down cover at any hour on every tier. Annualised: ₹3.6 lakh, ₹12 lakh, ₹30 lakh.
The decision rule, stated plainly. Under 40 measured hours a month and a single production environment: one owner, whether employed or fractional, is correct and three hires is waste. Over 80 measured hours a month, or infrastructure is the product, or you have a real 24/7 obligation with named response times in customer contracts: hire, and hire the platform or SRE role first. Between 40 and 80 hours: one senior owner plus purchased independence for testing, and revisit at the next funding event. Those numbers are hours of demand, not a judgement about the person.
9. Where three hires is also the wrong answer
The three-hire plan also fails for its own reasons, not just on cost. A three-person rotation is one week in three on call, forever, which is the section 3 problem in a smaller and more painful form. Three new hires arrive without context, and context is the expensive part: the undocumented reason a subnet exists, the service that cannot be restarted in the wrong order. Practitioner opinion: four to six months per senior infrastructure role at startup compensation bands is realistic, and three parallel searches do not run faster than one.
Then there is under-utilisation. If measured load is 30 hours a month, three full-time hires hold roughly 450 hours of capacity against 30 hours of work. Feature work fills the rest, which is how an infrastructure specialist becomes a backend engineer who no longer owns infrastructure, and the gap reopens with a bigger salary bill.
Takeaway: measure the hours first. Every staffing argument here is downstream of that number, and it is the one input most teams never collect.
The five triggers that mean you have outgrown one person
Practitioner checklist, and the short answer to "can one person really handle cloud, devops and security for a startup or do we need three hires" once you are past the first 15 engineers. Any two of these together is the signal to add a second infrastructure person rather than renegotiate the first:
- Measured infrastructure and security load is consistently over 80 hours a month.
- A customer contract names an out-of-hours response time one person and a deputy cannot meet.
- You are in PCI DSS scope, or a regulated process requires separated roles that a reviewer cannot satisfy.
- You run more than one production environment in more than one region.
- Your single owner is the only person who can deploy, and deployments wait on their calendar.
The honest summary table
| Duty | One person at under 15 engineers? | Why |
|---|
| Infrastructure as code | Yes | Build once, review as code, maintain on a schedule |
| CI/CD pipeline | Yes | Configuration work that runs without a human in the path |
| Baseline hardening | Yes | Published benchmarks, finite project |
| Identity and access | Yes | Tooling generates and reviews policy at this scale |
| Cost control | Yes | Monthly review cadence, not daily load |
| Continuous out-of-hours cover | No | A sustainable rotation needs bodies: 8 for one single-site rotation in the SRE book's model |
| Separation of duties | No | PCI DSS 6.5.4 separates roles; one author-approver-deployer fails the control design |
| Independent testing | No | PCI DSS 11.4 requires organizational independence of the tester |
Stage-specific recommendation
Pre-seed, under 10 engineers, one environment: hire none of the three. Give one existing senior engineer the named ownership, buy a scoped audit to find what is actually broken, and put the founder on the review duty. Measure the hours for a month before anything else.
Seed, 10 to 25 engineers: one owner, employed or fractional, plus purchased independent testing once or twice a year, plus a written incident procedure with a named deputy. This is the band where the question gets asked most and where three hires is most often wrong.
Series A, 25 engineers and up, or regulated: hire, in this order: platform or SRE first (the delivery path is the daily bottleneck), then security as a dedicated role once compliance commitments sit in customer contracts. Keep buying independent testing externally even then, because independence is the requirement and an employee cannot supply it for their own systems.
If you want the hours number before you write a job description
MatrixGard runs a free 20-minute review for early-stage founders: your estate, where the out-of-hours and separation-of-duties gaps actually sit, and an honest read on whether this is a one-owner setup or a genuine hiring problem. If the answer is that you should hire, you will hear that. No NDA for the first conversation. Send a note.
Avinash S is the founder of MatrixGard. Fractional DevSecOps for early-stage startups, funded or bootstrapped across India, the GCC, the UK, and the US. Almost a decade of building, breaking, and securing cloud infrastructure for fintech, healthtech, and SaaS workloads.
Methodology note. On-call staffing figures come from Google's Site Reliability Engineering book, chapters 11 and 5, as published at sre.google. PCI DSS requirement numbers (6.5.3, 6.5.4, 11.4) are cited from the PCI Security Standards Council document library; verify the wording against PCI DSS v4.0.1 before relying on it in an assessment. The SOC 2 reference is criterion CC6.3 of the AICPA 2017 Trust Services Criteria with 2022 revised points of focus. The reporting window is from Direction No. 20(3)/2022-CERT-In dated 28 April 2022, issued under section 70B(6) of the Information Technology Act, 2000. Salary figures are published aggregator averages, with sample size and date in the table; aggregator samples are self-reported and vary widely by seniority, city and employer type, so treat them as a starting point for your own arithmetic rather than a market rate. The fully-loaded multiplier, the hours thresholds, the search-duration estimate and the five triggers are practitioner opinion, labelled inline, not drawn from a published study. Retainer rates and the three-senior-hire figure are our own published numbers from matrixgard.com/pricing. This post describes no client engagement and contains no client outcomes.
