The audit is one of the few external pressures Filipino SMB owners take seriously. It is calendared, paid for, and closely watched. The auditor signs off, the report goes into the file, the business moves on with confidence that the controls are working.
This article is about what the audit does not cover. The reason most Filipino SMBs that get breached have just passed an audit is not because audits are bad. Audits are good at what they do. The problem is that the cyber attack surface lives mostly outside the audit's scope, and the assumption that one covers the other is causing real damage.
Below: what each type of audit actually checks, what they miss, and why the right answer is not "stop auditing" but "add the layer that audits cannot reach."
What your financial audit actually checks
Financial audits in the Philippines, conducted under PFRS or PSA standards by SGV, P&A, KPMG-equivalent firms, or smaller local practices, focus on the integrity of financial statements. The auditor verifies that revenue recognition matches the supporting documentation, that expenses are properly categorised, that assets and liabilities reconcile, and that the financial statements present a true and fair view.
Within that scope, controls testing happens. The auditor will ask whether segregation of duties is in place between the person who initiates a payment and the person who approves it. The auditor will sample journal entries to confirm that authorisations are documented. The auditor may verify that bank reconciliations are completed monthly and signed off.
This is good work. It is also a narrow slice. The auditor will not log into your Microsoft 365 tenant to check whether MFA is enabled. The auditor will not review the access list of your accounting software. The auditor will not test whether your firewall is exposing RDP to the public internet. The auditor will not run a simulated phishing campaign against your employees. None of those are within the scope of a financial audit. They were never meant to be.
So when a Filipino SMB owner says "we just had our audit," they are usually talking about a clean financial audit that confirms the books are in order. The cyber attack surface was not examined. It was, structurally, invisible to the audit.
What a SOC 2 or ISO 27001 audit catches that a financial audit does not
For SMBs that need to demonstrate security to customers (typically B2B BPOs, fintechs, or healthcare data processors), the next step up is a SOC 2 Type II or ISO 27001 audit. These are explicitly security-focused. They examine whether documented information-security controls exist, are documented, and are operating consistently over a period of time.
SOC 2 organises this around five Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. ISO 27001 organises around an Information Security Management System. Both produce a report that customers can use as evidence that you are managing security at a process level.
This is meaningfully more rigorous than a financial audit on the security dimension. The auditor will examine your access management policy. They will sample evidence that quarterly access reviews happen. They will check that backup procedures are documented and tested. They will verify that incident response runbooks exist.
What SOC 2 and ISO 27001 audits do not do is test whether the controls actually work against a real attacker. The auditor reads your policy that says "we enable MFA for all administrative accounts." They sample evidence that the policy was followed. They confirm the control is operating as designed. They do not attempt to bypass it.
This distinction is the heart of the article. The audit verifies process. The red team tests reality. They are different questions.
The territory the audit cannot reach
Here is a partial list of things a real attacker exploits that no audit reliably catches.
Reconnaissance against your visible online presence. Auditors do not Google your company. Attackers do. They pull your employees from LinkedIn, your domain's mail records from public DNS, your subdomains from certificate transparency logs, and your company's leaked credentials from previous data breaches. By the time they pick up the phone or write the phishing email, they know more about your operational structure than your auditor will ever ask about.
Identity-layer attacks. The audit confirms MFA is enabled. The attacker confirms that one specific employee has it disabled because she found the prompt annoying and IT made an exception. The attacker tests every account against credential dumps until one works. The audit's sampling methodology will not catch this; it is a Pareto-failure problem where one exception breaks everything.
Email-based social engineering. The audit confirms phishing-awareness training was delivered. The attacker writes a phishing email that mimics your CEO's actual writing style, references a meeting that actually happened, and uses internal jargon learned from 9 days of reconnaissance. Your employees fail to spot this because no training prepares them for an attacker who has read 90 days of their boss's email.
Cloud configuration drift. The audit examines your Microsoft 365 configuration at one point in time. Six months later the configuration has drifted because every change request from a new feature, a new tenant, a new external user has slowly accumulated. The audit's next sample is six months away. The attacker tests the configuration as it is today.
Supplier and partner exposure. The audit checks your vendors against your vendor risk policy. The attacker compromises one of your suppliers (often easier than compromising you), then sends a fraudulent email from the supplier's real domain. Your vendor risk policy has no defence against this because it assumes the supplier's identity is intact.
None of these gaps are auditor failures. They are scope failures. The audit was never designed to catch them. They live in the territory between disciplines.
How a red team complements your existing audit
The right relationship between an audit and a red team is sequential, not competitive.
Audit → red team → audit
Confirm controls are operated
The audit verifies your controls are documented and consistently in place. This is the foundation. Without it, every other security investment sits on sand.
Test controls against a real attacker
The red team checks whether those controls actually stop someone who is trying. The output is a list of paths that succeeded. Some are paths the audit thought were closed. Some are paths the audit never considered.
Feed findings back into the next audit
Controls that failed get strengthened. New controls get added to close the gaps the audit had not previously asked about. The next audit verifies the strengthened controls are operating consistently.
The output of this cycle, run annually, is genuinely defensible security. The audit alone produces compliance theatre. The red team alone produces a snapshot that decays. The combination produces continuous improvement that compounds.
For Filipino SMBs the practical implementation is simpler than it sounds. Most clients we work with run their financial audit annually with their existing audit firm, run a SOC 2 or ISO 27001 if customer requirements demand it, and run a red team engagement once every 12 to 18 months. The red team is the smallest of the three line items by cost (typically PHP 280,000 to PHP 850,000 versus PHP 600,000 to PHP 4 million for compliance audits) and the highest in marginal risk reduction.
The honest conversation with your auditor
If you have an existing audit relationship, the right move is to ask your auditor directly. Tell them you are evaluating whether to add a red team engagement and ask whether their work has covered the gaps a red team would address. A good auditor will tell you straight: yes, this is outside our scope, and yes, you would benefit from running both.
The auditors who push back tend to be the ones who have started selling adjacent security services and feel competitive pressure from independent red team firms. The professional response is the first one. The defensive response is a flag that the audit relationship is being managed by someone whose incentives are no longer aligned with yours.
For SMB owners who do not currently work with an auditor on the security dimension, the order is reverse. Do the red team first. The findings will tell you what your control gaps are. Then build out the policy and process layer (which a SOC 2 or ISO 27001 readiness consultant can help with) and audit it once it is mature enough to test.
Either order produces the same outcome. The point is that you need both layers, run by different people, looking at different parts of the same business.
Strategic frame
Filipino SMBs are reaching the size and customer profile where security expectations are no longer optional. International customers ask for SOC 2. Banking partners ask about cyber controls. The National Privacy Commission's enforcement is becoming more active. Insurance underwriters are starting to require evidence of security testing for cyber policies.
The owners we work with who handle this well do not treat security as a single line item. They treat it as a stack with three layers. The financial audit confirms the books. The compliance audit confirms the process. The red team confirms reality. Each layer answers a question the others cannot.
If you are running a Filipino SMB above PHP 50 million in annual revenue, the realistic question is which of those three layers you currently have, and which you are missing. For most owners the answer is that the financial audit is in place, the compliance audit may or may not be relevant, and the red team has never been done.
That last gap is the one the auditor cannot close, and the one we exist to fill.