How Often Should You Run a Penetration Test? The common answer is at least once a year, and again after any significant change to the application or the systems around it. That is also what the PCI DSS standard for card payments requires: testing at least every 12 months and after significant changes, using a documented method. For many businesses, those two triggers are enough to build a schedule around.<\/p>\n\n\n\n
The yearly test catches problems that arise as software ages and attackers learn new techniques. The change-based test catches problems you introduced yourself, since new features and new hosting settings are where fresh flaws appear.<\/p>\n\n\n\n
PCI DSS. Requirement 11.4 asks for penetration testing of internal and external systems at least every 12 months and after significant changes. It covers both network and application layers, calls for testers who are qualified and independent in the way the standard describes, and expects the problems found to be fixed and retested. If segmentation is used to reduce the scope of the payment environment, testing must also confirm that segmentation works, at least every 12 months for merchants, and every six months for service providers. Guidance on the standard says that vulnerability scanning is a separate requirement and does not stand in for a penetration test. Check the current version of the standard, or ask your assessor, before relying on any summary, including this one.<\/p>\n\n\n\n
Other standards and contracts. Other frameworks, customers, and insurers may ask for regular testing, often yearly. If a questionnaire or a contract asks about penetration testing, it will usually say how recent the last report must be. Read it before you plan the date.<\/p>\n\n\n\n
The exact threshold is a judgement call, and guides note that this trigger is easy to miss. These are the usual candidates.<\/p>\n\n\n\n
If you are unsure whether a change is significant, ask your tester or your assessor. A short conversation costs less than skipping a test you needed.<\/p>\n\n\n\n
The same rhythm works well: one test a year, plus one after major changes. If your application is small, rarely changes, and holds little sensitive data, you may stretch the gap. If you add features often, handle payments or personal data, or sit in an industry that attackers target, test more often, or test the new parts as they ship.<\/p>\n\n\n\n
Automated scanning between tests helps. A regular scan finds routine problems, such as missing patches, so your penetration tester can spend their time on harder ones. See penetration testing vs vulnerability scanning<\/a> and DAST vs penetration testing<\/a> for how the two fit together.<\/p>\n\n\n\n A report describes the system on the dates it was tested. As soon as the code, the configuration, or the hosting changes, it describes something slightly different. Auditors and customers usually want a report from within the last twelve months, and one that predates a major change counts for less. For your own planning, treat the report as a snapshot and your schedule as the thing that keeps it current.<\/p>\n\n\n\n These three are illustrative, and your own should reflect your risk and any rules you must follow.<\/p>\n\n\n\n A small business with a brochure website and a contact form holds little sensitive data. It might run a basic scan every quarter, keep software updated, and commission a test every year or two, or after a redesign.<\/p>\n\n\n\n An online store takes payments and holds customer details. It might scan monthly, test the store and its checkout every year, and test again after major changes such as a new payment provider or a platform migration. If it handles card data directly, the PCI DSS rules above apply.<\/p>\n\n\n\n A software company ships changes weekly and stores customers’ data. It might run automated scanning in its build pipeline, test each major release, and commission a full external test every year. It might also test new features that touch authentication or data access before they go live.<\/p>\n\n\n\n Testing production shows the real thing, including real configuration and hosting. It carries more risk, so it needs careful scope and timing. Testing staging is safer, and it works well if staging mirrors production closely. A mismatch is the danger: a staging copy with different settings can hide problems that exist on the live site. Many teams test staging for the bulk of the work and do a short, careful check of production for configuration items. Agree this with your tester before the work begins.<\/p>\n\n\n\n As soon as the fixes are in place, while the findings are fresh. A retest confirms that each fix works and that no new problem came with it. Many providers include a retest within a set period after the report, so ask about the window. Leaving it for months risks the fixes being forgotten or undone by later changes.<\/p>\n\n\n\n The most common failure is a test done once for a customer or an audit and never repeated, while the application keeps changing. The second is a test whose scope has quietly shrunk, so it no longer covers the parts that changed. The third is treating the date as the goal: a test is only useful if its findings are fixed. The fourth is forgetting to tell the tester about changes since the last round, which makes them re-discover your system from scratch.<\/p>\n\n\n\n Share a short list of what has changed since the last test: new features, new integrations, a new hosting setup, changes to login or permissions, and any incidents. That helps the tester focus on the risky parts and saves time. Our web application penetration testing checklist<\/a> covers what else to prepare, and the post on penetration testing cost<\/a> explains how scope affects the price. For a view of how testing differs from scanning, read penetration testing vs vulnerability scanning<\/a>.<\/p>\n\n\n\n For many organisations it is a reasonable baseline, and some standards require it. If you change your application often, add features that handle sensitive data, or have recently had an incident, test more often or after each major change.<\/p>\n\n\n\n Often yes, particularly if the redesign changes how login, payments, or data handling works, or moves the site to a new platform or host. A purely visual refresh on the same platform is a lower risk, but ask your tester.<\/p>\n\n\n\n A qualified security specialist, either internal or external. Standards such as PCI DSS expect testers to be qualified, and customers often prefer an independent third party. Ask about their method, experience, and sample reports before you hire.<\/p>\n\n\n\n If something has gone wrong, the first job is to contain it and find out what happened. That is incident response, and it is a separate activity from a penetration test. Once the immediate problem is dealt with and the cause is fixed, a penetration test is a sensible way to confirm that the same route, and similar ones, are closed. Tell your tester what happened, so they can check the affected parts first.<\/p>\n\n\n\n An incident is also a good moment to review the rest of your schedule. If it took an attacker one overlooked weakness to get in, ask whether the rest of your applications have been tested recently, and bring forward any that have not.<\/p>\n\n\n\n We scope each test on a short call and send a proposal with the timeline, the deliverables, and transparent pricing. If you want help setting up a testing schedule, see our web application penetration testing services<\/a>, or contact us<\/a>.<\/p>\n\n\n\n Most organisations test at least once a year and again after major changes. Here is what standards like PCI DSS require and what else should trigger a new test.<\/p>\n","protected":false},"author":1,"featured_media":2015,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[50,48,14,49],"class_list":["post-1015","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-cybersecurity","tag-compliance","tag-pci-dss","tag-penetration-testing","tag-security-testing"],"_links":{"self":[{"href":"https:\/\/krylo.co\/insights\/wp-json\/wp\/v2\/posts\/1015","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/krylo.co\/insights\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/krylo.co\/insights\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/krylo.co\/insights\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/krylo.co\/insights\/wp-json\/wp\/v2\/comments?post=1015"}],"version-history":[{"count":1,"href":"https:\/\/krylo.co\/insights\/wp-json\/wp\/v2\/posts\/1015\/revisions"}],"predecessor-version":[{"id":2034,"href":"https:\/\/krylo.co\/insights\/wp-json\/wp\/v2\/posts\/1015\/revisions\/2034"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/krylo.co\/insights\/wp-json\/wp\/v2\/media\/2015"}],"wp:attachment":[{"href":"https:\/\/krylo.co\/insights\/wp-json\/wp\/v2\/media?parent=1015"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/krylo.co\/insights\/wp-json\/wp\/v2\/categories?post=1015"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/krylo.co\/insights\/wp-json\/wp\/v2\/tags?post=1015"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}How should you plan your testing calendar?<\/h2>\n\n\n\n
\n
How long does a report stay useful?<\/h2>\n\n\n\n
What do example schedules look like?<\/h2>\n\n\n\n
Should you test production or a staging copy?<\/h2>\n\n\n\n
How soon should you retest after fixes?<\/h2>\n\n\n\n
What goes wrong with testing schedules?<\/h2>\n\n\n\n
What should you tell your tester about changes?<\/h2>\n\n\n\n
Quick answers<\/h2>\n\n\n\n
Is once a year enough?<\/h3>\n\n\n\n
Do I need a penetration test after a redesign?<\/h3>\n\n\n\n
Who can perform the test?<\/h3>\n\n\n\n
What about testing after a security incident?<\/h2>\n\n\n\n
How Krylo can help<\/h2>\n\n\n\n
Sources<\/h2>\n\n\n\n
\n