The Peruvian software standard the State requires (NTP-ISO/IEC 12207)

If you work at a public entity and you are about to contract a development, there is a standard that already binds you and that rarely enters the conversation until someone notices it missing from the tender documents. And if you are a supplier bidding for government work, it is the standard you can be asked for without warning.

What is required, and of whom

Ministerial Resolution N° 041-2017-PCM, issued on 27 February 2017, approved the mandatory use of NTP-ISO/IEC 12207:2016 —“Software and Systems Engineering. Software life cycle processes, 3rd edition”— across every entity of the National Informatics System.

This is not recent news: it replaced R.M. N° 179-2004-PCM, which had approved the 2004 edition of the same standard. The Peruvian State has been requiring a software life-cycle framework for more than twenty years; what changed in 2017 was the edition in force.

The obligation binds the entity, not the supplier. In practice it reaches the supplier through the tender documents: if the entity must comply, it will require the contracted service to align with it.

What 12207 is

It is the Peruvian adoption of ISO/IEC 12207. It provides a common reference framework for the software life cycle: from the conceptualisation of an idea through to its retirement, covering the acquisition, supply, control and improvement processes.

In Peru it is developed by CTN-ISSI, the technical committee for informatics and information systems standardisation, and it comes with two companion guides: NTP-ISO/IEC 15271 for implementation and NTP-ISO/IEC 16326 for project management.

The full text of the standard is not freely available —it is acquired through the standardisation channel— so you will not find its clauses here. What you can take away is what it means when you have to apply it.

The costliest misreading: it is not a methodology

12207 defines processes, not a development model. It does not prescribe waterfall, it does not forbid sprints, and it does not force you to freeze requirements.

What it asks is that the processes exist, are defined and leave evidence. A team working in iterations complies perfectly well if it documents how scope is defined, how a deliverable is accepted, how changes are controlled and how verification happens.

The opposite reading —“the standard forces us to write a giant document before coding”— is what produces public projects that deliver binders instead of systems. The standard does not ask for that.

What it means when you write the TDR

This is where the standard stops being theory. If you are the entity, your requirements document should state which life-cycle processes will be followed and what evidence will be delivered for each — not only which features you want.

That is exactly the work we go through in how to write a TDR for custom software. And the next piece, the terms under which it is delivered, is covered in the software development contract in Peru, because the standard tells you how to work but not who ends up owning the code.

What the standard does not settle

If you are a supplier

Knowing it is cheap and it positions you. In a bid it lets you answer the tender documents in their own language, propose what evidence you will deliver at each process, and avoid the argument about whether your way of working “counts” — because it does, and now you can explain why.

In our case the framework is not theoretical: UNJFSC's central cashier is a system in production inside a national university, with the traceability that environment demands.

In short

NTP-ISO/IEC 12207 has been mandatory across the Peruvian State since 2017 and defines the software life-cycle framework, not the methodology you build with. If you are contracting, put it in the TDR with its associated evidence. If you are bidding, read it for what it is: a common way of talking about process, not an obstacle.