In brief
pTrackly got ISO 27001 certified in 7 weeks: 3 weeks of readiness, then a 4-week audit. What made it possible, and why it is our case, not a promise.
pTrackly got ISO 27001 certified in 7 weeks: 3 weeks to audit readiness, then a 4-week audit from Stage 1 through Stage 2 to certification by an independent certification body. This is our own certification, and a customer has since reached the same timeline. It is an example of what a running ISMS makes possible, not a promise: a different scope or starting point gives a different timeline.
What does "certified in 7 weeks" actually cover?
The 7 weeks cover two phases with two different owners. The first 3 weeks were readiness, which was our work: confirming that every control in scope had an owner, a published policy, current evidence and a review schedule. The next 4 weeks were the certification audit, which the certification body runs: a Stage 1 review of the ISMS design and documentation, then a Stage 2 audit of whether the controls operate, under the rules in ISO/IEC 17021-1. The 7 weeks do not include the months of normal operations before readiness started, and they say nothing about how long a team starting from zero would need.
| Phase | Duration (our case) | Who controls the clock | What happened |
|---|---|---|---|
| Operating the ISMS | Months before readiness | pTrackly | Policies, tasks, reviews, risks and assets were already run in the platform day to day |
| Readiness | 3 weeks | pTrackly | Verified owners, policies, evidence and review dates for each control; closed gaps |
| Stage 1 to Stage 2 audit | 4 weeks | Certification body | Documentation review, then the operating-effectiveness audit and the certification decision |
Why were 3 weeks enough for readiness?
Readiness was verification, not creation. Most controls in our ISO/IEC 27001:2022 scope were already operating, because we run the same platform we sell to customers: policies, evidence tasks, review cycles, risks and assets were all managed in pTrackly before the audit was booked. So the readiness question for each control was not "how do we implement this?" but "can we show this control is operating as intended?" That meant checking four things per control:
- It has a named owner.
- Its supporting policy is published, with a signed approval and a next review date.
- Its evidence tasks are current, with timestamps, the person who submitted them and an independent approver.
- It is linked to the relevant risks and assets where the standard expects that.
Where one of those four was missing, we fixed it inside the 3 weeks. Nothing had to be written from scratch the week before the auditor arrived.
How was evidence ready before the audit started?
Evidence was an operating activity, not an audit task. Each evidence task in pTrackly has a frequency (daily to yearly) and a review date, and the platform sends reminders 7, 3 and 1 days before a review falls due. Evidence is linked to the controls it proves, so when the auditor asked for user access reviews, backup checks, vulnerability management records, asset inventories, training records or internal review notes, we pulled them from the control instead of searching email and shared drives. Some tasks are checked by integrations; others are uploaded or linked by their owner. Either way, the history showed who submitted and who approved each item, which is what an auditor looks for when judging whether a control ran over time.
How did documentation stay in line with how we actually work?
Policies were reviewed on a schedule and whenever a process changed. Each policy in pTrackly has a review frequency, an approver who cannot be its own author, and a signed record of the approved version. When a process changed, the policy and its linked controls were reviewed together and republished, and employees accepted the new version. The result was that the auditor evaluated how we actually operate, not documents written for the certificate. If policies need a major rewrite in the weeks before an audit, the management system has already fallen behind the organization it describes.
What did the 4-week audit focus on?
The audit was a validation exercise. Because readiness had been done continuously, meetings were spent showing how controls operated, how responsibilities were assigned, how reviews were performed, how risks were treated and how improvements were tracked, rather than looking for documents. That is what ISO 27001 is designed to assess: a management system that plans, operates, checks and improves (clauses 4 to 10), with Annex A controls selected through risk treatment and recorded in the Statement of Applicability. We used the audit workspace to answer the auditor's request list against linked evidence.
What did we learn from our own certification?
Four lessons came out of it, and they are the ones we now build around:
| Lesson | What it means in practice |
|---|---|
| Continuous compliance is faster than project-based compliance | A temporary audit team every year repeats the same work; spreading it across daily operations removes most of the pre-audit rush |
| Evidence is worth more when it is collected at the time | Proof gathered months later is harder to find and less convincing; proof captured on a schedule is already there |
| Good documentation follows operations | Policies should describe how the organization works now, and be reviewed when that changes |
| Ownership matters more than paperwork | A control with a named owner gets reviewed; a control owned by "everyone" does not |
What changed in pTrackly because of it?
Going through the audit ourselves showed us where compliance teams lose time, and we used that to refine parts of the platform: evidence tasks with frequencies and review dates, policy approval and review cycles, control ownership, reminders, controls shared across frameworks, compliance scores per framework, and the audit workspace where an auditor works through the request list. What the platform does not do is decide your scope, operate your controls or certify you. Your team owns the ISMS and its decisions; an accredited certification body runs the audit and issues the certificate.
What happens after the certificate?
Certification starts a three-year cycle, not a finish line. The certification body returns for surveillance audits during the certificate's validity and a recertification audit before it expires, and between them new employees, infrastructure changes, suppliers and risks keep arriving. We run the same routine after certification that got us ready: scheduled evidence, scheduled policy reviews and a risk register that is reviewed on a cadence. Maintaining ISO 27001 after certification covers that routine in detail, and how long ISO 27001 certification takes explains the factors that make a timeline longer or shorter.
If you are planning your own certification, start with the ISO 27001 framework page and the ISO 27001 implementation checklist for Vietnamese IT outsourcing companies.
Frequently asked questions
Can any company get ISO 27001 certified in 7 weeks?
No. Our 7 weeks (3 weeks of readiness, then a 4-week audit) depended on an ISMS that was already operating. A company starting without policies, owners or evidence needs time to build and run them first, and the certification body sets its own audit schedule.
Who issued pTrackly's ISO 27001 certificate?
An independent, accredited certification body audited and certified pTrackly. pTrackly prepares controls and evidence for its customers but never certifies anyone.
Is the 7-week timeline only pTrackly's own case?
It is pTrackly's own certification and also a customer case with the same 3 weeks of readiness and 4-week audit. Both are examples with a specific scope and starting point, not a commitment for other organizations.
What took the most time during readiness?
Verifying that each control had an owner, a published policy and current evidence, and fixing the few that did not. Very little time went into writing new documents, because the ISMS was already running.
Want to see how pTrackly keeps an ISMS audit-ready between audits? Book a demo.
