ISO 27001 Mandatory Documents: The Real List of 15 for the 2022 Edition

Every document ISO/IEC 27001:2022 actually requires, who owns it, what a Stage 2 auditor asks to see against it — and the ones the toolkit vendors invented.

Short answer

ISO/IEC 27001:2022 requires exactly fifteen items of documented information. Not forty, not a two-hundred-page manual, and not a separate policy for each of the 93 Annex A controls. The fifteen sit in clauses 4.3, 5.2, 6.1.2, 6.1.3, 6.1.3 d), 6.2, 7.2, 7.5.1 b), 8.1, 8.2, 8.3, 9.1, 9.2.2, 9.3.3 and 10.2. Everything beyond those fifteen is there because you determined it necessary under clause 7.5.1 b) — and the moment you do, it becomes auditable.

The Statement of Applicability, at clause 6.1.3 d), is the only document the standard names outright. It is also the one that fails most often at Stage 2, because the justification column has been left as boilerplate.

Mandatory items

Fixed by ISO/IEC 27001:2022. The number does not vary by company size.

Mandatory manual

None

ISO 27001 has never required an “information security manual”.

Named document

SoA only

Clause 6.1.3 d) — the Statement of Applicability.

Annex A policies

Not per-control

A.5.1 asks for a policy set, not 93 separate documents.

This page is the documentation companion to our full guide on ISO 27001 certification in the Philippines. If you are looking for the control list rather than the document list, see all 93 Annex A controls and the evidence each one needs.

The fifteen mandatory documents, clause by clause

Below is the complete list as ISO/IEC 27001:2022 states it. The first two columns are the standard’s own clause numbers and the documented information each clause requires. The third and fourth are ours: who typically owns the document in a Philippine implementation, and what an accredited auditor actually opens at Stage 2. The standard does not assign owners and does not tell auditors what to ask for — those columns are twenty years of implementation experience, and we label them as such rather than dressing them up as requirements.

Clause	Documented information required	Typical owner	What a Stage 2 auditor asks to see
4.3	Scope of the ISMS A written scope statement covering the boundaries and applicability of the ISMS, including interfaces and dependencies with other organisations.	CISO or ISMS manager, signed off by top management	The scope statement, and then a walk of one interface named in it – a client, a data centre, an outsourced help desk – to test whether the boundary you wrote is the boundary you actually operate.
5.2	Information security policy A top-level policy appropriate to the purpose of the organisation, including objectives or a framework for setting them, and commitments to satisfy applicable requirements and to continually improve.	Top management (approval); ISMS manager (drafting)	The signed policy, the date of approval, and evidence it was communicated to staff and made available to interested parties as required.
6.1.2	Information security risk assessment process The documented process itself: risk criteria including risk acceptance criteria, how risks are identified, analysed and evaluated, and how repeated assessments produce consistent, valid and comparable results.	Risk owner or ISMS manager	The methodology document, then a re-run of one risk through it to confirm two assessors would land in the same place.
6.1.3	Information security risk treatment process How treatment options are selected, how necessary controls are determined, and how the result is compared against Annex A to confirm nothing necessary was omitted.	ISMS manager with risk owners	The process, and the trace from one assessed risk to the control that treats it and to its line in the Statement of Applicability.
6.1.3 d)	Statement of Applicability (SoA) Mandatory and named in the standard. Must contain the necessary controls, the justification for their inclusion, whether each is implemented, and the justification for excluding any Annex A control.	ISMS manager, approved by management	The SoA in full, and a challenge on two or three exclusions. A blank or boilerplate justification column is the single most common Stage 2 finding we see in this market.
6.2	Information security objectives Objectives at relevant functions and levels: measurable where practicable, monitored, communicated and updated, with a plan stating what will be done, what resources are required, who is responsible, when it completes and how the results are evaluated.	Function heads, consolidated by the ISMS manager	The objectives and the five planning elements clause 6.2 requires. “Improve security awareness” with no owner, date or measure fails.
7.2	Evidence of competence Evidence that the people whose work affects information security performance are competent, and evidence of any action taken where they were not – not a training matrix for its own sake.	HR with the ISMS manager	Competence records for named individuals in security-affecting roles, and what you did about the gaps you found.
7.5.1 b)	Documented information determined necessary by the organisation The open clause. Whatever else your ISMS needs in order to work – procedures, standards, registers – becomes mandatory the moment you determine it is necessary.	ISMS manager	Your own document list. Auditors read this clause more often than implementers expect: if your access control procedure exists, it is auditable, and “it was only a draft” is not a defence.
8.1	Operational planning and control records Documented information to the extent necessary to have confidence that ISMS processes have been carried out as planned. Also covers control of planned changes, review of unintended changes, and control of externally provided processes, products and services relevant to the ISMS.	Process owners	Records that the process ran – change tickets, approvals, review minutes – not just the procedure that says it should.
8.2	Results of the information security risk assessment The output, not the method: the assessed risks, their owners and their evaluated levels, at defined intervals and whenever significant changes occur.	Risk owners	The risk register with dates, and evidence of a reassessment triggered by a significant change rather than only by the calendar.
8.3	Results of the information security risk treatment Including the risk treatment plan, risk owners’ approval of it, and their acceptance of the residual information security risks.	Risk owners	The treatment plan and the named approval of residual risk. An unsigned residual-risk acceptance is a nonconformity, not an administrative detail.
9.1	Evidence of the monitoring and measurement results What is monitored and measured, by which methods, when, by whom, and when the results are analysed and evaluated. The clause requires the methods to be defined before the numbers are produced.	ISMS manager with IT operations	The measurement definitions and at least two cycles of actual results, with the analysis that followed them.
9.2.2	Evidence of the audit programme(s) and the audit results The programme – frequency, methods, responsibilities, planning requirements and reporting – and the results themselves, considering the importance of the processes concerned and the results of previous audits.	Internal audit function or appointed internal auditor	The programme, the audit reports, auditor independence from the area audited, and evidence that last year’s findings shaped this year’s programme.
9.3.3	Results of management reviews Documented information as evidence of the results of management reviews, which must include decisions on continual improvement opportunities and any need for changes to the ISMS.	Top management	Minutes covering every input clause 9.3.2 lists and showing decisions, not just attendance. A review with no decision is a meeting, not a management review.
10.2	Nonconformities, actions taken and results of corrective action Evidence of the nature of the nonconformities and any subsequent actions taken, and the results of any corrective action.	ISMS manager with the affected process owner	The nonconformity log with root cause, action, and verification of effectiveness. Note the 2022 numbering: 10.1 is Continual improvement and 10.2 is Nonconformity and corrective action, the reverse of 2013.

Note the 2022 numbering. In ISO/IEC 27001:2022, 10.1 is Continual improvement and 10.2 is Nonconformity and corrective action — the reverse of the 2013 edition. Any consultant, template or internal procedure still citing “10.1 Nonconformity” is working from a withdrawn document, and that is worth knowing before you pay them.

What ISO 27001 does not require

More money is wasted on documents ISO 27001 never asked for than on any other line of an ISMS project. Four myths in particular are worth killing before you write a word.

The myth	What the standard actually says
You need an “Information Security Manual”	There is no such requirement anywhere in ISO/IEC 27001:2022. The concept came from old quality-management practice and was dropped from every Annex SL standard. If a template vendor is selling you a manual, they are selling you a habit, not a requirement.
You need a documented procedure for every Annex A control	Annex A controls are controls, not documents. Many are demonstrated by configuration, logs or observed practice. A.5.1 asks for information security policies to be defined and approved — a coherent policy set, not 93 separate files.
You need six mandatory procedures	That is ISO 9001:2008 folklore, and even ISO 9001 dropped it in 2015. ISO 27001 has never listed six mandatory procedures.
Everything must be a Word document	Clause 7.5.2 requires appropriate format and media. A ticketing system, a configuration baseline in code, or a GRC platform record is documented information if it is identified, approved and controlled. Auditors accept systems of record; they do not accept unversioned files on someone’s laptop.

The practical consequence: a well-run 40-person Philippine company certifies against a document set of roughly 25 to 35 items — the fifteen mandatory ones plus the procedures and registers it genuinely needs. A toolkit that ships 120 files does not make you more compliant. It makes you responsible for keeping 120 files current, and every one you cannot evidence is a finding waiting to happen.

Clause 7.5.1 b): the clause that makes your own documents mandatory

Clause 7.5.1 says the ISMS shall include documented information required by the standard and documented information the organisation determines is necessary for the effectiveness of the ISMS. That second limb, 7.5.1 b), is the one implementers underestimate.

It works in both directions, and only one of them is comfortable:

In your favour: nothing beyond the fifteen is imposed on you. You decide what your ISMS needs. A 25-person software company does not need a physical security procedure for a data centre it does not operate.
Against you: the moment you determine a document is necessary — or simply write one and put it into circulation — it falls under 7.5.2 and 7.5.3 and is auditable like any other. An access control procedure that exists but has not been reviewed in three years is a nonconformity you created for yourself. “It was only a draft” is not a defence if staff are following it.

The test we apply on every Sterling project: for each document beyond the fifteen, can you name the risk it treats or the process it makes repeatable? If not, do not write it. Deleting a document you never needed is far cheaper before Stage 1 than explaining it afterwards.

Clause 7.5.2: what every document must carry

When creating and updating documented information, clause 7.5.2 requires the organisation to ensure appropriate identification and description, appropriate format and media, and review and approval for suitability and adequacy. In practice, three things must be visible on the face of the document or in the system holding it.

7.5.2 requirement	What it means in practice	Where implementations fail
Identification and description	Title, date, author or owner, and a reference — enough that two people discussing “the access policy” are certain they mean the same document.	Three files called Access Control Policy final v2 (revised).docx in three different folders.
Format and media	Language your staff actually read, a format they can open, and media appropriate to how the document is used. Electronic, paper or platform record are all acceptable.	English-only procedures for a workforce that operates in Filipino on the floor, so nobody reads them and the awareness interview at Stage 2 goes badly.
Review and approval	A named approver and a date, before the document goes live. Suitability and adequacy are the two tests the clause names.	A signature block that has never been signed, or a policy “approved” by the consultant who wrote it rather than by anyone in your organisation.

Clause 7.5.3: controlling documented information

Clause 7.5.3 requires that documented information be available and suitable for use where and when it is needed, and adequately protected — for example from loss of confidentiality, improper use, or loss of integrity. It then lists the activities you must address as applicable: distribution, access, retrieval and use; storage and preservation, including preservation of legibility; control of changes such as version control; and retention and disposition. Documented information of external origin that you determine is necessary must be identified as appropriate and controlled.

Two points from that clause are worth pulling out because they are routinely missed in Philippine implementations.

Access is a two-level decision. The standard notes that access can imply permission to view only, or permission and authority to view and change. If everyone in your shared drive can edit the risk register, you have not controlled it — you have shared it. This is the single easiest finding for an auditor to raise, because it takes thirty seconds to test.
Documented information of external origin is in scope. Client security requirements, a regulator’s circular, a vendor hardening guide you rely on: if you determined it necessary, it must be identified and controlled. Working from an obsolete client security schedule is a real-world incident, not just an audit point.

Retention is your decision, not the standard’s. ISO/IEC 27001 does not prescribe retention periods. Your retention schedule should be driven by contractual commitments, Philippine legal and regulatory requirements, and evidentiary need. What your certification body will expect is that records covering the current certification cycle remain retrievable — you cannot demonstrate continual improvement at a recertification audit if you disposed of last year’s evidence.

Documents versus records — and why the split still matters

ISO/IEC 27001 uses one term, documented information, for both. That harmonised wording came in with the Annex SL high-level structure and both the 2013 and 2022 editions use it. But the distinction the old wording described has not gone away, and it is the fastest way to see why a shelf full of policies still fails Stage 2.

	Documents (what you intend to do)	Records (evidence it happened)
Examples from the fifteen	Scope (4.3), policy (5.2), risk assessment process (6.1.2), risk treatment process (6.1.3), SoA (6.1.3 d), objectives (6.2)	Competence evidence (7.2), operational records (8.1), risk assessment results (8.2), treatment results (8.3), monitoring results (9.1), audit results (9.2.2), management review results (9.3.3), corrective action (10.2)
Changes over time?	Yes — versioned, reviewed, reapproved	No — a record of what happened on a date does not get edited later
What an auditor does with it	Reads it, then tests whether practice matches it	Counts it, dates it, and samples it against the population
Common failure	Beautifully written, never followed	Never generated at all, because nobody ran the process

Count the split: six of the fifteen are documents, eight are records, and the fifteenth — clause 7.5.1 b) — is whatever else you determine necessary. That ratio is the whole message. An ISMS is not a documentation exercise with some evidence attached; it is an operating system that happens to produce eight categories of evidence. Companies that fail Stage 2 almost never fail on the six — they fail because the eight do not exist yet.

Why a bought toolkit fails Stage 2

We are asked about ₱15,000 documentation toolkits constantly, so here is the direct answer: a template pack is a starting format, not an ISMS. It fails in four specific, predictable ways, and an experienced auditor finds all four inside the first hour.

The SoA justification column is generic. Clause 6.1.3 d) requires justification for inclusion and justification for exclusion. “Not applicable — no such activity” repeated eleven times is not a justification, and it is the most common Stage 2 finding we see in this market.
The risk assessment does not match the business. A template risk register lists risks the vendor imagined. Clause 6.1.2 requires your criteria and your identified risks, with named owners. An auditor asks one question — “who owns this risk and when did you last speak to them?” — and the template collapses.
There are no records. Eight of the fifteen items are records of things happening. No toolkit can sell you an internal audit you have not run or a management review you have not held.
Nobody in the company recognises the documents. Stage 2 includes interviews with staff who are not on the project team. If the procedure describes a process your operations team has never heard of, the finding is not documentary — it is a finding that your ISMS is not implemented.

This is the same objection we raise about shortcut certification generally. A certificate obtained on documents nobody follows survives exactly until your first client security audit or your first breach — and by then it is your reputation on the line, not the toolkit vendor’s.

The Philippine overlay: Data Privacy Act documents are separate

Philippine companies frequently assume that an ISO 27001 document set discharges their obligations under Republic Act No. 10173, the Data Privacy Act of 2012. It does not. The two regimes overlap heavily in substance and not at all in law.

Obligation	Source	Is it one of the fifteen?
Information security policy, scope, SoA, risk assessment, internal audit, management review	ISO/IEC 27001:2022	Yes — these are the fifteen.
Privacy manual or equivalent privacy programme documentation	Data Privacy Act of 2012 and its Implementing Rules and Regulations, as administered by the National Privacy Commission	No. Separate obligation. Many clients place it in the ISMS document set under 7.5.1 b), which is sensible, but it is not an ISO 27001 requirement.
Appointment of a Data Protection Officer	Data Privacy Act of 2012 and NPC issuances	No. ISO 27001 requires competence and assigned responsibilities, not a DPO by name.
Registration of data processing systems and breach notification to the NPC	NPC registration and breach-notification requirements	No. Your ISMS incident process should trigger the NPC notification workflow, but the obligation is statutory and independent of certification.
Records of personal data processing activities	Data Privacy Act regime	No — though ISO/IEC 27701, the privacy extension to 27001, does address this directly and is the cleanest way to bring the two together.

If personal data is central to your business — BPO, fintech, healthcare, e-commerce — build the privacy documentation and the ISMS documentation as one set from day one. Retrofitting privacy onto a finished ISMS costs more than doing both at once, and it is exactly the sequencing mistake we spend most of our remediation time undoing.

Amendment 1:2024 and your documentation

ISO/IEC 27001:2022/Amd 1:2024 adds to clause 4.1 a requirement to determine whether climate change is a relevant issue, and adds a note to clause 4.2 that interested parties can have climate-related requirements. It changes no Annex A control.

What that means for your document set, precisely:

It adds no sixteenth mandatory document. Clause 4.1 has never been one of the fifteen — the standard requires you to determine issues, not to document the determination.
But auditors will ask. The practical answer is to record the determination wherever you already keep your context and interested-parties analysis. That register is a 7.5.1 b) item you almost certainly maintain already.
A one-line “not relevant” is acceptable if it is true and reasoned. For a Philippine organisation it usually is not the whole answer: typhoon exposure, grid instability and flood risk at a site are climate-related issues with direct availability consequences, and they belong in your risk assessment on their merits.

The order to build them in

Sequence matters more than speed. Six of the fifteen are documents you write; eight are records you can only generate by running the ISMS. Trying to produce the eight before the six exist is what turns a six-month project into a fourteen-month one.

Phase	What you produce	Why this order
1. Define	Scope (4.3), information security policy (5.2)	The scope sentence is printed on your certificate and determines the audit duration and therefore the fee. Get it wrong and every downstream document is scoped wrong too.
2. Assess	Risk assessment process (6.1.2), risk treatment process (6.1.3), risk assessment results (8.2)	Controls are an output of risk, not an input. Selecting controls first and reverse-engineering risks to fit is visible to any competent auditor.
3. Decide	Statement of Applicability (6.1.3 d), treatment results and residual risk acceptance (8.3), objectives (6.2)	The SoA is a conclusion. It can only be written honestly once the risk work above it is real.
4. Operate	Operational records (8.1), competence evidence (7.2), monitoring and measurement results (9.1), plus the procedures you determined necessary under 7.5.1 b)	This is the phase that cannot be compressed. You need enough operating history for the evidence to be meaningful — typically three months minimum before Stage 2.
5. Check	Internal audit programme and results (9.2.2), management review results (9.3.3), nonconformities and corrective action (10.2)	A certification body will not proceed to Stage 2 without a completed internal audit and management review. These are the two most common reasons a Stage 2 date slips.

Sterling Academy · e-learning for your people

Training that stands up in your ISO 27001 audit

Sterling consulting clients benefit from preferential course access and special pricing on Sterling Academy through their Sterling consultant, including complimentary ISO 27001 awareness training for your people as part of your engagement. Your consultant sets up your client administrator, you add your people, and every learner who completes a course and its final exam receives a numbered Certificate of Completion, verifiable online.

Completion records and certificates are your evidence for ISO/IEC 27001:2022 clauses 7.2 (competence) and 7.3 (awareness) and for Annex A control 6.3, information security awareness, education and training — the items a certification auditor tests by interviewing your staff.

Courses for an information security management system

End to end with Sterling: your ISO 27001 engagement includes

Implementation consulting through Design™ (guided) or Drive™ (fully managed), up to the certification audit
Sterling Academy e-learning for your people: preferential course access and special pricing, with complimentary ISO 27001 awareness training
Live internal auditor training for your audit team
Effivity ISMS software subscription
Vulnerability assessment by Cyber Vantage 360
Sustain™ post-certification support: internal audits, management reviews and surveillance preparation

List price from US$19 per learner per course (51–200 learners) · 12 months’ access · final exam included

Certificate of Completion issued after the final exam, numbered and verifiable online · Sterling consultant, client administrator and learner roles as on Sterling Academy

ISO 27001 mandatory documents: frequently asked questions

1. How many mandatory documents does ISO 27001:2022 require?
Exactly fifteen items of documented information, in clauses 4.3, 5.2, 6.1.2, 6.1.3, 6.1.3 d), 6.2, 7.2, 7.5.1 b), 8.1, 8.2, 8.3, 9.1, 9.2.2, 9.3.3 and 10.2. Toolkits that advertise forty or more documents are counting items the standard leaves to your discretion under clause 7.5.1 b).

2. Does ISO 27001 require an information security manual?
No. There is no requirement for a manual anywhere in ISO/IEC 27001:2022. The idea is inherited from older quality-management practice and was dropped from every Annex SL standard. A manual is optional; if you write one, it becomes auditable documented information like anything else.

3. Is the Statement of Applicability mandatory?
Yes. Clause 6.1.3 d) names it directly. It must contain the necessary controls, the justification for including each one, whether each is implemented, and the justification for excluding any Annex A control. It is the only document ISO/IEC 27001 names outright, and the one most often found deficient at Stage 2.

4. Do I need a documented procedure for every Annex A control?
No. Annex A lists controls, not documents. Many controls are demonstrated through configuration, logs, contracts or observed practice rather than a written procedure. A.5.1 requires information security policies to be defined and approved — a coherent policy set, not 93 separate files.

5. Can our ISO 27001 documents live in a GRC platform instead of Word files?
Yes. Clause 7.5.2 requires appropriate format and media, not a particular file type. A platform record that is identified, approved, version-controlled and access-controlled satisfies 7.5.2 and 7.5.3 better than a shared drive does. Auditors accept systems of record routinely; what they reject is unversioned files with no approval trail.

6. How long must we keep ISO 27001 records?
ISO/IEC 27001 does not prescribe retention periods — clause 7.5.3 requires you to address retention and disposition, and you set the periods based on contractual, legal and evidentiary need. In practice keep everything covering the current three-year certification cycle, because recertification examines the trend across it.

7. Does Amendment 1:2024 add a new mandatory document?
No. Amendment 1:2024 adds a requirement in clause 4.1 to determine whether climate change is a relevant issue and a note to clause 4.2 about climate-related requirements of interested parties. Clause 4.1 is not one of the fifteen, so no sixteenth document is created — but record the determination in your context register, because auditors are asking for it.

8. Do ISO 27001 documents satisfy the Philippine Data Privacy Act?
No. The Data Privacy Act of 2012 and the National Privacy Commission impose separate obligations, including privacy programme documentation, a Data Protection Officer, registration and breach notification. They overlap with an ISMS in substance but not in law. If personal data is central to your business, build both document sets together, or use ISO/IEC 27701 to bridge them.

9. How many documents do Philippine companies actually end up with?
A well-run 40-person organisation typically certifies on 25 to 35 items: the fifteen mandatory ones plus the procedures and registers it genuinely needs. More is not better. Every document you cannot evidence as current and followed is a finding you created for yourself.

10. Can we buy a template pack and certify on it?
You can buy one as a starting format, but you cannot certify on it unchanged. Eight of the fifteen items are records of things actually happening — internal audits, management reviews, monitoring results, corrective actions — and no vendor can sell you an activity you have not performed. Stage 2 also interviews staff outside the project team, which is where template-only implementations fail.

Build fifteen documents that hold, not forty that do not

Sterling writes ISMS documentation against your actual risk assessment, your actual scope and your actual processes — and we tell you which documents you do not need. If a template pack would genuinely serve you better, we will say so.

Talk to a Sterling ISO 27001 consultant

11. Is training included with Sterling’s ISO 27001 consulting?
Every Sterling engagement includes live internal auditor training for your audit team and preferential access to Sterling Academy, with complimentary ISO 27001 awareness training for your people as part of the engagement. Special pricing applies to the wider catalogue — Information Security Essentials, 93 Annex A Controls (ISO/IEC 27002:2022) and Risk Management — through your Sterling consultant. Learners who complete a course and its final exam receive a numbered Certificate of Completion, verifiable online, and the completion records serve as evidence for clauses 7.2 and 7.3 and Annex A control 6.3.

Where to go next

ISO 27001 certification in the Philippines — the complete guide: clauses, controls, process and timeline.
All 93 Annex A controls — each control and the evidence a Stage 2 auditor asks for.
ISO 27001 certification cost in the Philippines — published consulting and certification-body ranges.
Risk assessment and the Statement of Applicability — how to write an SoA that survives Stage 2.
Internal audit and management review — the two records that most often delay a Stage 2 date.
ISO 27001 vs ISO 27002 — requirements against guidance, and why only one of them certifies.
ISO 27001 for fintech in the Philippines — BSP, NPC and SEC supervision, cloud scoping and the diligence pack banks ask for.

Written and maintained by the ISO 27001 practice at Sterling International Consulting, Philippines. All clause and control references are to ISO/IEC 27001:2022 including Amendment 1:2024. Last updated: 1 August 2026.