Then the Stage 2 auditor asks a simple question: "How do you know you're meeting that objective?"

Silence. A spreadsheet that was last updated in March. A screenshot of an AWS dashboard nobody reviews.

This is where most technology companies struggle with ISO 14001 certification. Not on intent, but on measurement. The good news: if you run a modern DevOps stack, you already have most of the monitoring you need. You just aren't pointing it at environmental performance yet.

What ISO 14001 expects you to measure

ISO 14001 is the international standard for an Environmental Management System (EMS). Four clauses drive almost everything an auditor checks on measurement:

The key word in clause 6.2 is measurable. "Be more sustainable" isn't an objective. "Reduce compute emissions per active user by 15% this financial year" is.

Step 1: Turn environmental aspects into metrics

Start with your aspects register and attach a metric and a data source to each one:

Notice how many of these overlap with cost metrics. Idle compute, over-provisioned clusters and stale data all cost money and energy. FinOps and environmental management point in the same direction, which makes objectives much easier to get leadership buy-in for.

Step 2: Write objectives like you write config

Treat your environmental objectives like any other version-controlled configuration. A simple file in your internal repo works well, and it doubles as audit evidence:

# ems-objectives.yml – ISO 14001 clause 6.2
fy: 2026-27
objectives:
  - id: ENV-01
    aspect: cloud_compute
    target: "Reduce compute emissions per active user by 15%"
    baseline: "FY 2025-26 average"
    metric: kgco2e_per_active_user
    source: cloud_carbon_dashboard
    owner: platform-team
    review: monthly
  - id: ENV-02
    aspect: idle_resources
    target: "Auto-shutdown on 100% of non-prod environments outside working hours"
    metric: nonprod_envs_with_schedule_pct
    source: iac_policy_check
    owner: devops-team
    review: monthly
  - id: ENV-03
    aspect: e_waste
    target: "100% of retired devices disposed through authorised recyclers"
    metric: devices_disposed_authorised_pct
    source: asset_register
    owner: it-ops
    review: quarterly

Each objective has an owner, a metric, a data source and a review frequency. That covers almost everything clause 6.2 asks you to plan.

Step 3: Automate the controls

Clause 8.1 (operational planning and control) expects you to control the processes linked to your significant environmental aspects. For an IT company, that's mostly infrastructure policy, which you can automate:

• Scheduled shutdown of dev and staging environments outside working hours

• Infrastructure-as-code policy checks that block oversized instance types without approval

• Storage lifecycle rules that move or delete data past its retention period

• Region selection guidelines that favour cloud regions with a lower-carbon energy mix where latency allows

• Build caching to cut redundant CI pipeline minutes

Each automated policy is a control that runs every day, and its logs are evidence an auditor can sample.

Step 4: Build one dashboard and actually review it

Clause 9.1.1 isn't satisfied by having data. It needs you to evaluate it. Pull your metrics into one dashboard (Grafana, your BI tool, or even a shared sheet fed by exports) and review it on a fixed schedule:

• Monthly: the platform or DevOps team reviews cloud and pipeline metrics

• Quarterly: IT operations reviews devices and e-waste

• Annually: leadership reviews everything in the management review (clause 9.3)

Record each review, even briefly: date, attendees, what was off-track and what you decided. Those records are exactly what the auditor asks to see.

Step 5: Don't forget compliance evaluation

Clause 9.1.2 requires you to periodically check that you're meeting your compliance obligations. For Indian IT companies, the E-Waste (Management) Rules, 2022 are the most common one. Keep disposal certificates from authorised recyclers, and review them at least once a year. Client contracts with sustainability clauses count as compliance obligations too.

Common audit findings in IT companies

• Generic aspects registers copied from a manufacturing template, listing boilers and effluent instead of cloud and devices

• Objectives with no baseline, so nobody can tell whether 15% was achieved

• Dashboards that exist but are never reviewed, with no records of evaluation

• E-waste handed to unauthorised scrap dealers, with no disposal certificates

• No link to the management review, so leadership never sees environmental performance

ISO 14001 alongside your other standards

ISO 14001 uses the same high-level structure as ISO 9001 and ISO 27001, so IT companies that already hold either one can extend their existing internal audit and management review to cover environmental management too.

Companies with large office or campus footprints often add ISO 45001 for occupational health and safety, and those running critical infrastructure add ISO 22301 for business continuity. For a closer look at how ISO 9001 maps to agile workflows, see ISO 9001 for software teams.

The ISO 14001 certification process

1. Define the EMS scope: offices, remote operations and services delivered

2. Build your environmental aspects register and attach metrics

3. Map compliance obligations, including e-waste rules and client requirements

4. Set measurable environmental objectives with owners and baselines

5. Automate operational controls and start collecting data

6. Run an internal audit and management review

7. Pass the Stage 1 and Stage 2 audits by an accredited certification body

8. Maintain certification with annual surveillance audits over a three-year cycle

Choose an accredited certification body so your certificate is accepted by enterprise clients and tender authorities. SIS Certifications is accredited by IAS, IAF and UAF, and its guide to ISO 14001 certification explains the full process.

FAQ

Can a cloud-only SaaS company get ISO 14001 certification? Yes. Your environmental aspects are cloud usage, devices, offices and travel. Cloud providers' carbon reports give you measurable data for objectives.

What's the most important clause for IT companies? Clauses 6.2 and 9.1. Measurable objectives with real monitoring evidence are where most IT companies are weakest.

How long does ISO 14001 certification take for an IT company? Usually three to six months, most of it spent collecting enough monitoring data to show the system works.

Is ISO 14001 the same as carbon neutrality? No. ISO 14001 certifies that you manage and reduce environmental impacts through a system. Carbon neutrality is a separate claim about offsetting emissions.

Leadership decides to go for it. A few weeks later, someone from the compliance side asks the engineering lead for "evidence of secure development practices."

Most developers assume ISO 27001 is a paperwork exercise that happens somewhere else in the company. In reality, a big chunk of the controls auditors check sit inside your repos, pipelines and cloud console.

A quick primer on ISO 27001

ISO 27001 is the international standard for an Information Security Management System (ISMS). The 2022 version groups its security controls in Annex A into 93 controls across four themes: organisational, people, physical and technological.

The technological theme (section 8 of Annex A) is where engineering work lives. The 2022 revision also added new controls that map directly to modern dev practices, such as secure coding, configuration management and data leakage prevention.

The certificate covers your management system, not your product. An auditor won't pentest your app. They'll check that you have controls in place, that you follow them and that you can show evidence.

The Annex A controls developers actually own

There's also 5.23 (information security for cloud services), another 2022 addition. It covers how you choose, use and exit cloud providers. If your whole stack runs on AWS, GCP or Azure, expect questions about shared responsibility and how you manage access to the console.

What an audit of a dev team looks like

The auditor picks a recent change and asks you to trace it. Where's the ticket? Who reviewed the PR? Did the pipeline run security scans? Who approved the deploy to production? Could the developer who wrote the code push it to prod alone?

If your branch protection requires reviews, your CI runs SAST and dependency checks, and production deploys need an approval step, you've just produced most of your evidence without writing a single extra document.

Where dev teams usually get caught out

• Production access creep. Developers who were given prod access "temporarily" two years ago and still have it. Auditors check access reviews.
• Vulnerability alerts nobody triages. Hundreds of open Dependabot alerts with no defined patch timeline. Have a severity-based SLA and stick to it.
• Secrets in repos. API keys in old commits or .env files. Use a secrets manager and scan history.
• Test data that's actually production data. Control 8.33 expects test data to be protected. Copying a prod database to staging without masking is a common finding.
• Hotfixes outside the process. The 2 a.m. fix pushed straight to main. Emergency changes need a recorded, retrospective review.

When ISO 27001 isn't enough on its own

If your clients are US enterprises, they'll often ask for a SOC 2 report too. The controls overlap heavily, so one set of engineering practices can serve both.

If you process personal data, ISO 27701 adds privacy controls on top of ISO 27001. That's increasingly relevant in India with the DPDP Act coming in.

And if you ship AI features, ISO 42001 covers AI governance, including model risk, data quality and human oversight, and shares the same management system structure.

How certification works

1. Define the ISMS scope (for example, "development and operation of [product] SaaS platform")
2. Run a risk assessment and pick applicable Annex A controls
3. Write a Statement of Applicability explaining which controls apply and why
4. Implement controls and collect evidence, which is where engineering does most of the work
5. Run an internal audit and management review
6. Pass the Stage 1 and Stage 2 audits by an accredited certification body
7. Maintain the certificate with annual surveillance audits over a three-year cycle

Check accreditation before choosing a certification body, since procurement teams often reject certificates from unaccredited bodies. SIS Certifications is accredited by IAS, IAF and UAF, and its guide to ISO 27001 certification explains the full process.

FAQ

Do developers need to write lots of documentation for ISO 27001? Not much. The auditor wants evidence that controls work. PR history, CI logs and access settings usually count.

Does ISO 27001 require penetration testing? Not explicitly, but control 8.29 requires security testing, and pentests are one of the most common ways to show it.

How long does ISO 27001 take for a SaaS company? For a well-organised engineering team, often three to six months from gap analysis to certificate.

Can ISO 27001 be combined with ISO 9001? Yes. They share the same high-level structure, so many software companies run ISO 9001 and ISO 27001 together. See our earlier post on ISO 9001 for software teams.

That's usually the moment a software company starts taking ISO 9001 seriously.

What is ISO 9001 for a software company?

ISO 9001 is the international standard for a quality management system (QMS). For a software company, it means showing that you have a defined, repeatable way to capture requirements, design, build, test, release and fix your product, and that you improve that process based on evidence. It doesn't prescribe tools, languages or a methodology. Scrum, Kanban and hybrid setups all qualify.

The certificate covers your management system, not your product. An auditor won't test your app. They'll check whether the way you build it is controlled and consistent.

How ISO 9001 clauses map to your dev workflow

The standard runs from clause 4 to clause 10. Here's what each one asks, translated into things most dev teams already do (or half-do).

Clause 8 is where software teams spend most of their audit time, and 8.3 (design and development) in particular. The auditor wants to see that requirements become design inputs, that design gets reviewed, and that what you shipped was verified against what was asked for.

Agile and ISO 9001 aren't enemies

There's a stubborn belief that ISO 9001 forces you into waterfall and 200-page procedure manuals. That was closer to true in the 1990s. The 2015 revision dropped the mandatory quality manual and the six mandatory procedures, and replaced them with "documented information", which you decide the format of.

In practice, an audit of an agile team looks like this. The auditor picks a feature that shipped last quarter and asks you to walk it through. Where's the user story? What were the acceptance criteria? Who reviewed the pull request? Where are the test results? How was the release approved? If your Jira tickets link to GitHub PRs, and your CI logs show tests passing before merge, you've just produced your evidence. No separate paperwork needed.

The teams that struggle are the ones where that trail breaks: a story with no acceptance criteria, a hotfix pushed straight to production with no record, a release decided over a phone call.

Where software teams usually fall short

After enough of these audits, the same gaps show up again and again:

• Supplier control (8.4). AWS, Stripe, a third-party auth provider and the two freelance developers you hired last year are all external providers. ISO 9001 expects you to have criteria for choosing them and to review how they perform. Most teams have never written this down.

• Corrective actions that never close (10.2). Postmortems get written. The five action items at the bottom sit in a doc nobody opens again. Auditors pick up on that quickly.

• Quality objectives without review. You track deployment frequency and bug counts on a dashboard, but nobody compares them against a target or decides what to do when they slip.

• Internal audit left to the last minute (9.2). It's meant to be a genuine check of your own system, run by someone who isn't auditing their own work. A rushed audit a week before Stage 1 tends to show.

None of these need new tools. They need someone to own them.

How ISO 9001 certification works, step by step

1. Define your scope. For example: "Design, development and support of [product] SaaS platform." Keep it tight. A narrower scope is easier to certify and you can extend it later.

2. Run a gap analysis. Compare your current practices against each clause and list what's missing.

3. Close the gaps. Write your quality policy, set quality objectives, map your core processes and fix the weak spots above.

4. Operate the system. Run it for a couple of months so you have real records: reviews, metrics, corrective actions.

5. Do an internal audit and a management review. Leadership looks at the results and decides on improvements.

6. Stage 1 audit. The certification body checks your documentation and readiness.

7. Stage 2 audit. The auditor checks that the system is actually implemented, usually by sampling real work.

8. Certification. The certificate runs on a three-year cycle, with surveillance audits every year.

One thing to check before you sign with anyone: accreditation. A certificate from an unaccredited body often won't satisfy procurement teams or tender authorities. Look for a body accredited by an IAF member, and confirm that ISO 9001 is within its accredited scope. SIS Certifications publishes its accreditations (IAS, IAF and UAF) and lets clients verify certificates online, which is the kind of transparency you should expect from any certification body.

Is ISO 9001 worth it for a small dev shop?

If you sell to enterprises, government departments or regulated industries like banking and healthcare, yes. It moves you past the procurement filter, and the discipline it forces (traceable requirements, closed corrective actions) tends to cut rework.

If you build a consumer app and no buyer has ever asked for it, probably not yet. Spend the effort on your product instead.

One practical note: ISO 9001 shares its high-level structure with ISO 27001. If your clients are also asking about information security, run both together. Clauses 4 to 10 line up, so one internal audit and one management review can cover both, and ISO 27001 certification becomes a much smaller second step.

FAQ

Does ISO 9001 apply to software companies? Yes. ISO 9001 applies to any organisation, of any size, in any sector. Software companies are among the most common certificate holders in IT services.

How long does ISO 9001 certification take? For a small, organised software team, three to six months from gap analysis to certificate is common. Most of that time goes into running the system long enough to produce records.

Does ISO 9001 certify my software product? No. It certifies your quality management system: how you plan, build, deliver and improve. It says nothing about whether a specific release is bug-free.

What's the difference between ISO 9001 and ISO 27001? ISO 9001 covers quality: consistent delivery and customer satisfaction. ISO 27001 covers information security: protecting the confidentiality, integrity and availability of data. Many software companies hold both.