ISO 27001 Internal Security Audit Template in Jira

An ISO 27001 internal audit is a required part of the standard and a core element of your audit program. It must run on a schedule and produce audit results that are clear enough to show during a management review and, later, an external audit.

Most teams don’t struggle with what to check. ISO 27001 already defines clauses, Annex A, and expected audit activities. The real challenge is execution: running the same internal audit processes every cycle, across teams, with clear ownership, evidence, and follow-up.

Here’s what usually breaks:

• No clear internal audit plan. The audit schedule slips, and scope becomes vague.
  
• Weak ownership and independence. Work isn’t assigned, or the same internal auditor reviews their own area.
  
• Evidence is scattered. Controls exist, but proof lives across Confluence pages, tickets, spreadsheets, and screenshots without a single trail.
  
• Findings don’t turn into action. Audit findings stop at notes instead of turning into action items, corrective action, and an action plan with owners and deadlines.
  

A structured workflow solves the practical part: it keeps audit work consistent, helps stakeholders track progress in real time, and makes follow-up unavoidable.

If you’ve seen our “Template for Compliance Audit in Jira” post, the idea is similar. Jira works as the audit tracker: owners, due dates, status, and evidence links. Your policy documentation stays in your documentation system.

What an ISO 27001 internal audit actually covers (and what it doesn’t)

ISO certification is granted to the company, with a defined scope

ISO 27001 certification applies to an organization and its quality management system / security management processes, then it’s limited by scope.

Teams often talk about “a product being ISO certified” because that’s what customers care about, but the certificate is tied to the company and the defined scope of operations around that product or service. At the same time you have to keep in mind that a company can be ISO certified with the scope limited to one product’s development and operations.

Scope is the first decision in every internal audit plan

Your internal auditor starts by defining scope and criteria. This keeps the audit program focused and makes audit results comparable across cycles.

Typical scope options:

• One product or service line
  
• One department or process group (e.g., procurement, vendor onboarding, incident response)
  
• The full ISMS scope (broader, heavier)
  

What can be out of scope depends on your reality. If you don’t operate a physical data center or office infrastructure, you can exclude parts of physical security and treat cloud providers (AWS/GCP) as vendors under procurement and supplier controls.

What auditors actually validate

An ISO 27001 internal audit checks whether your internal controls match what’s written and how work actually happens. It’s less about “do you have a policy” and more about “can you prove it was followed.”

What this looks like in practice:

• Evidence-based checks: approvals, access control configuration, logs, vendor reviews, training confirmations, incident records
  
• Working papers: notes or checklists showing what was reviewed, which audit questions were asked, and what evidence supported the conclusion
  
• Follow-up: audit findings become action items, a corrective action plan, owners, and due dates
  

Remote audits made this even more evidence-driven. Stakeholders rarely “walk” an auditor through a physical office now. Teams share documents, screenshots, exports, and meeting notes, then track remediation through the audit workflow.

ISO 27001 Internal Audit Checklist Template

Jira as your audit tracker and execution layer

Use Jira to run the internal audit process as a repeatable workflow: plan the audit, assign owners, track audit activities, and close corrective actions.

Keep long-form security documentation where it already lives (often Confluence). Jira links to it and captures audit evidence, decisions, and follow-up in a way that’s easy to validate during an external audit.

What Jira gives you during an ISO 27001 internal audit:

• clear ownership (assignee / internal audit team)
  
• an audit schedule with dates and statuses
  
• traceability for audit findings, nonconformance, and corrective action
  
• a single action plan view for stakeholders and management review
  

In order to make this repeatable process structured create a checklist that defines:

• audit questions to cover
  
• evidence to collect (links, screenshots, exports)
  
• outcome fields (conformity / OFI / non-compliance)
  
• action items with owners and due dates

ISO 27001 Internal Audit Checklist 

This checklist structure works for one product scope, a department scope (e.g., procurement), or a full ISMS scope.

Note: Scope is always the first decision. If something is out of scope (for example, physical security when you don’t operate a physical data center), keep the section but mark it as Out of Scope with a short justification. That makes the audit results easier to validate.

ISO 27001 Internal Audit Checklist Template

Use this as the backbone of your internal audit checklist. To turn this ISO 27001 internal audit checklist into a reusable checklist template in Smart Checklist for Jira, open any Jira issue, add the checklist items in Smart Checklist (paste the Markdown list or type items), then click the Smart Checklist menu (?) and select Save as template. 

Name it something like “ISO 27001 Internal Audit Checklist”, choose whether it should be project or global, and save. 

Add checklists to your Jira tasks

• Add and edit items
• Make recurring templates
• Automate them with your conditions
• Tag colleagues, add deadlines
• View a progress bar

Try it free

After that, you can import the template into any audit work item (issue) or set it as a default so every new internal audit issue starts with the same checklist.

Keep evidence audit-ready without turning Jira into a document archive

An internal audit lives or dies on evidence. Auditors don’t want a perfect story. They want to see that your internal controls exist, people follow them, and you can prove it with artifacts.

In Jira, each audit work item (issue) should hold lightweight “working papers”:

• A link to the source document (usually in Confluence or your doc repository)
  
• A screenshot/export when needed (policy version history, access review export, vendor assessment record)
  
• A short comment explaining what was reviewed and what changed (or that it stayed valid)
  

ISO is strict about review cadence. Even if nothing changed, you still need proof that the review happened. The simplest pattern is a template like:
“Annual review: {{policy_name}} — confirmed relevant ({{date}})”
…plus a link to the document and a quick confirmation comment from the owner.

This approach keeps the audit trail clear for stakeholders, supports validation, and makes it easy to produce an internal audit report later because every result and action item is already tied to a specific issue.

How to run the internal audit in Jira

Here’s a simple internal audit process you can repeat every audit cycle. It aligns with how ISO audits are expected to run, without turning your team into auditors.

1) Plan the audit (objectives, scope, schedule, independence)

Start with the Epic and confirm three things in the Audit Planning & Scope issue:

• Audit objectives: what you want to validate (e.g., “verify ISO 27001 controls are implemented and effective within scope”).
  
• Scope: what parts of the organization, product, or ISMS you’re checking this cycle.
  
• Audit schedule: key dates, deadlines, and interview windows.
  
• Independence: assign audit activities so auditors aren’t auditing their own work (at least for the most critical controls).
  

Practical Jira setup:

• Add due dates and assignees per issue.
  
• Use checklist items as “done criteria” so the audit plan isn’t vague.
  

2) Execute the audit (controls, sampling, evidence)

Inside each operational area issue (Access Control, Vendor Management, Logging, etc.), the team does three things:

• Validate the control exists (policy/procedure is defined and current).
  
• Validate the control works in practice (sample evidence, records, screenshots, exports).
  
• Capture results directly in the issue: what you checked, what you found, and links to evidence.
  

Example: Vendor risk assessment must happen if you have vendors.
So the audit step is not “do we have a vendor policy?” but “show me the latest vendor reviews and evidence they were completed.”

3) Log findings and create corrective actions

When something doesn’t meet requirements, treat it as a trackable outcome:

• Nonconformance (NC): a required control is missing or not working.
  
• Observation / OFI: improvement opportunity, not a failure (but still worth tracking).
  

In Jira, don’t bury findings in comments. Create:

• A dedicated Finding issue (or a sub-task) with owner + due date
  
• A checklist for the root cause and corrective action plan
  
• A clear “verification” step to confirm the fix is effective
  

4) Management review (close the loop with leadership)

Auditors will ask for proof that leadership reviewed audit results.

In Jira, this is easy:

• Add a Management Review issue with a short checklist:
  
  • review results
    
  • approve action plan
    
  • confirm deadlines and owners
    
• Attach evidence: meeting notes link, decision summary, or a recording reference (whatever your company uses)
  

5) Follow-up and close

Close the audit only when:

• All findings have owners and deadlines
  
• Corrective actions are completed or actively tracked
  
• You can show “before – after” evidence for key fixes
  

This is how internal audits protect you: if you catch and fix issues internally, external auditors usually won’t count them as findings in the same way, because you already proved your internal audit process works.

Examples of what teams usually audit first (ISO-focused)

If you’re building an internal audit program from scratch, start with areas that have clear evidence and repeatable audit activities. These sections also map cleanly to Jira issues + checklist templates.

1) Supplier and vendor management

ISO gets very concrete here: if you use vendors, you need a vendor risk assessment process.

What to check during the audit:

• Vendor list is complete (including SaaS and infrastructure vendors).
  
• Vendor risk assessments exist and were reviewed on schedule.
  
• Contracts include security clauses where required.
  
• Critical suppliers are monitored and re-reviewed regularly.
  

What “evidence” looks like in Jira:

• Link to the vendor register (Confluence/Excel).
  
• A “review completed” note with date and owner.
  
• Attachments or links to completed assessments for a sample of vendors.
  

2) ISMS documentation review (Clauses 4–10)

ISO 27001 expects an ISMS that points to all security documentation in one place.

What to check:

• ISMS scope statement is current and matches what you actually operate.
  
• Policies and procedures are version-controlled and easy to trace.
  
• Annual review is documented even if nothing changed.
  

Evidence example from the session:

• A tool like Drata can show timestamps and version history, which is strong audit evidence.
  
• In Jira, you can track the review task itself and link to the policy version or review record.
  

3) Risk assessment and treatment (Clause 6)

ISO doesn’t force one methodology. It cares that risk management exists, is repeatable, and reviewed by more than one person.

What to check:

• Risk assessment is documented and recent.
  
• High-likelihood + high-impact risks are not ignored.
  
• Historical incidents feed back into risk scenarios (example: “WordPress” incident becomes a tracked risk).
  
• Treatment decisions are clear (mitigate/accept/transfer/avoid) and have owners.
  

Where SoA connects:

• Risks – treatment decisions – selected controls – Statement of Applicability should line up.
  

4) Operational controls (Clause 8 + Annex A)

This is the biggest section, so teams often audit it in “blocks”:

• Access control: MFA, provisioning/deprovisioning, privileged access, password policies.
  
• Asset management: inventory, owners, classification, alerts for missing devices.
  
• Logging & monitoring: collection, alert handling, review evidence (e.g., suspicious login detection).
  
• Change management: approvals for normal changes, tracking for emergency changes.
  
• Incident management: incident handling, lessons learned, annual testing.
  
• BC/DR: plans, test results, improvements.
  
• Cryptographic controls: encryption policies, key management.
  
• Physical security: include only if it’s in scope (no data center or office controls = often excluded).
  

Tip for scoping: If you’re remote-first with cloud infrastructure, you may exclude data center physical security, but you still audit cloud providers as vendors on a regular cadence.

Management review and leadership involvement (the part teams forget)

ISO 27001 expects security to be driven by leadership, not delegated “somewhere in the team.” That’s why management review shows up as a repeatable requirement, not a one-time event.

In practice, auditors look for two things:

1. a clear organizational structure (who decides, who owns which internal controls), and
   
2. proof that top management reviewed the internal audit results and agreed on the next steps.
   

What to document for ISO in Jira

Create one dedicated issue inside your ISO 27001 Internal Audit epic:

Issue: Management review — ISO 27001 internal audit (Clause 9)

Keep the checklist short and evidence-focused:

• Confirm who is accountable for the ISMS (roles and responsibilities).
  
• Review the internal audit report (audit findings, nonconformance items, and audit results summary).
  
• Approve the corrective action plan (owners, due dates, action items).
  
• Record decisions and follow-ups (what changed, what stays, what gets re-tested).
  

What counts as evidence (simple and audit-ready)

Auditors don’t need a long narrative. They need traceability.

Examples that work well:

• A meeting note (Confluence link) with decisions and attendees (stakeholders / audit committee members).
  
• A recording or calendar entry titled like “Internal Security Audit Review.”
  
• A sign-off artifact in your compliance tool (e.g., a “tick” in Drata) plus a link from Jira.

Metrics and reporting

Keep reporting simple. The goal is to track progress and make follow-ups visible to stakeholders.

In Jira, you only need a few real-time indicators:

• Audit status: how many audit activities are Done / In Progress / Blocked.
  
• Audit findings: number of nonconformance items + opportunities for improvement.
  
• Corrective actions: open action plan items, owners, and due dates.
  
• Overdue items: anything past the audit schedule or corrective action deadline.
  

If you want a lightweight view for leadership, use a small dashboard or filter that shows:

• open noncompliance / nonconformance issues,
  
• corrective action tickets by assignee,
  
• upcoming management review date,
  
• overdue action items.
  

Add checklists to your Jira tasks

• Add and edit items
• Make recurring templates
• Automate them with your conditions
• Tag colleagues, add deadlines
• View a progress bar

Try it free

Conclusion

ISO 27001 gives you a clear audit checklist. Your challenge is execution: keeping the internal audit repeatable, traceable, and easy to review.

Jira helps you run the audit as a workflow:

• clear scope and objectives,
  
• ownership and audit schedule,
  
• evidence links in the right issues,
  
• corrective actions tracked to completion,
  
• management review captured as a final checkpoint.

If you want to reuse the same structure every audit cycle, Smart Templates creates the audit epic and issue set, and Smart Checklist keeps each step actionable with checklist templates and mandatory items.

FAQ on Internal Security Audit Template in Jira

What is an ISO 27001 internal audit?
An internal audit is a structured review of your ISMS and internal controls to confirm they match ISO 27001 requirements and how your team actually operates.

How often should ISO 27001 internal audits be performed?
At least once per year, as part of your audit program. Many teams run smaller internal audits more often to reduce risk.

Is ISO 27001 certification for a product or a company?
ISO 27001 is granted to a company, with a defined scope. The scope can be limited to a product, service, or part of the organization.

What is ISMS in ISO 27001?
ISMS is your Information Security Management System: the set of policies, procedures, roles, risk management, and controls that define how you run security.

What is a Statement of Applicability (SoA)?
A one-page list of ISO controls where you mark what applies to your scope, what doesn’t, and why. It must align with risk treatment decisions.

What evidence should I collect for an ISO internal audit?
Evidence can be policy links, version history, risk assessment outputs, vendor reviews, access control records, log review proof, incident reports, and management review notes.

Can I run ISO internal audits in Jira Cloud or Data Center?
Yes. The workflow (epic + issues + checklists + follow-ups) works in both Jira Cloud and Data Center. What changes is how your apps and integrations are deployed.

How do you track corrective actions after an audit?
Create one issue per corrective action, assign an owner, set a due date, link it to the audit finding, and review status during management review.

What should be included in an internal audit checklist?
Scope and plan, ISMS documentation review, risk management, SoA, operational controls (Annex A), audit findings, corrective actions, and follow-up reporting.

Article by Viktoriia Golovtseva

Content Marketing Manager at TitanApps. I turns complex tech products into clear stories and build content & marketing workflows, bringing higher ROI for tech companies. For 10 years, I’ve been helping B2B SaaS companies across content strategy, content operations, and product marketing, supporting go-to-market (GTM) programs, product adoption, and cross-functional execution. My sweet spot sits where product, marketing, and community meet.