Technology companies build their internal audit functions late, fast and under a deadline, which is usually an IPO twelve to eighteen months away, and the function that results looks different from any other industry’s. It is small (three to eight people at a company with thousands of employees), heavy on IT, security and data skills, co-sourced for the SOX program that was the reason it was founded, and it works inside an organization whose culture treats process as friction and whose controls live in code, configuration and cloud consoles rather than in approvals and reconciliations. The risks are different too: revenue recognition on subscription and usage contracts, the integrity of the operating metrics investors value the company on, the security of the product customers trust with their data, the privacy regimes of every country the product sells into, and, since 2024, the AI the product increasingly contains.
This guide explains how the function works at software, SaaS, platform and fintech companies: why tech audit is different; when and how the function is founded; the regulatory frame; the SaaS-specific financial risks; product security and the engineering control environment; the shape of a tech company’s audit universe; agile methods that fit the culture; what the audit committee sees; careers and pay; the failures that recur; and worked examples from Halberd Software, the pre-IPO B2B software company used in the technology examples on this site, and Helder Payments B.V., the Dutch payment institution whose DORA audit the DORA guide describes. The pre-IPO SOX readiness guide covers the program that founds most tech functions, and the IT audit plan guide the technology coverage at its core.
In this guide
- Why tech internal audit is different
- Founding the function: the pre-IPO clock
- The regulatory frame
- SaaS-specific financial risks
- Product security and the engineering control environment
- Privacy, AI and the rules that follow the product
- The shape of a tech company’s audit universe
- Agile methods that fit the culture
- What goes to the audit committee
- Careers and pay in tech internal audit
- Failures that recur
- A worked example: Halberd Software’s pre-IPO function
- A worked example: Helder Payments’ DORA year
- Questions about internal audit at tech companies
- Related guides
Why tech internal audit is different
Five features of the sector shape the function. Controls live in systems: a SaaS company’s revenue is computed by a billing platform from usage data and contract terms, its access is governed by identity providers and infrastructure-as-code, its changes ship through continuous deployment pipelines dozens of times a day, and its segregation of duties is enforced by configuration; an auditor who cannot read a pipeline definition, a cloud IAM policy or a billing rules engine cannot test the controls that matter. Growth outruns process: the company doubled headcount twice before anyone wrote a policy, acquisitions arrive with their own stacks, and the finance function is a year behind the product. The product is the risk: a security breach, an outage or a privacy violation in the product is an existential event in a way a factory defect rarely is, and customers’ own auditors (through SOC 2 reports, security questionnaires and contractual audit rights) are a standing audience. Investors value metrics: annual recurring revenue, net revenue retention, customer counts and gross margin drive valuation, are not governed by accounting standards, and are computed by analysts from systems nobody audited until the IPO prospectus. Culture: engineering organizations are flat, fast, skeptical of authority and allergic to documentation, and a function that arrives with checklists fails; one that arrives with evidence, speaks the stack and ships findings as fast as the teams ship code earns a place. The setting up an internal audit function guide covers founding a function in general; this guide covers founding one here.
Founding the function: the pre-IPO clock
Most tech internal audit functions are born of the IPO. A newly public company must have an audit committee of independent directors (exchange rules), management must assess internal control over financial reporting from the second annual report (SOX 404(a)), and the auditor must attest to it once the company is an accelerated filer and no longer an emerging growth company (404(b), with the JOBS Act’s five-year exemption for emerging growth companies under the revenue threshold), so boards and auditors expect a function before the listing. The sequence that works: hire a first chief audit executive fifteen to eighteen months before the expected listing, usually a senior manager or director from a large firm or a public tech company with SOX and IT audit experience; stand up the SOX readiness program first, with a co-source firm doing the heavy documentation and testing under the CAE’s direction, because the deadline is fixed and the committee’s first question will be about it; build the risk assessment and universe in parallel, so that the function is not only a SOX function when the listing happens; hire two to four auditors with IT, security and data skills, since the finance controls will be co-sourced and the technology controls will not; and negotiate the charter, the reporting line to the audit committee chair and the private sessions before the first board meeting, because tech boards are new to the arrangement and will accept what they are offered first. Functions founded this way face a known trap: three years after the IPO they are still 80 percent SOX, the committee has never seen an operational audit, and the risks the company actually faces (product security, privacy, metrics, cloud cost) are covered by nobody. The pre-IPO SOX readiness guide covers the program and the first 90 days as CAE guide the negotiation.
| Months before listing | Function milestone | Why then |
|---|---|---|
| 18 to 15 | First chief audit executive hired; charter and reporting line negotiated with the audit committee chair-designate; co-source firm engaged for SOX readiness | Readiness needs two closes to design and test; the board is forming |
| 15 to 12 | SOX scoping (materiality, significant accounts, locations, systems); risk and control matrices drafted; ITGC scoping of the in-scope systems; first risk assessment and universe | Scoping errors here cost the most later |
| 12 to 9 | Two to four auditors hired (IT audit, security, data); remediation of design gaps underway; first operational audit (usually revenue and billing, or access management) scheduled | The function must exist beyond SOX before the listing |
| 9 to 6 | Walkthroughs and design testing complete; remediation tracked; metrics definitions and controls documented for the prospectus; cybersecurity disclosure controls designed | Prospectus drafting needs the metrics and cyber processes |
| 6 to 0 | Operating effectiveness testing of key controls; audit committee charter and annual agenda adopted; first committee reports; disclosure committee operating | The company lists with evidence, not plans |
| 0 to 12 after | First 404(a) cycle; first full risk-based plan with 40 to 60 percent of hours outside SOX; the external quality assessment scheduled within five years | Avoid the SOX-only trap |
The regulatory frame
| Regime | Who it reaches | What it requires | Internal audit’s role |
|---|---|---|---|
| Sarbanes-Oxley and SEC rules | US-listed companies | 404(a) management ICFR assessment from the second annual report; 404(b) auditor attestation when no longer an emerging growth company and accelerated; 302 and 906 certifications; disclosure controls | Runs or supports the SOX program; tests ICFR; audits the disclosure process |
| SEC cybersecurity disclosure rules (effective December 2023) | SEC registrants | Form 8-K Item 1.05 disclosure of material cybersecurity incidents within four business days of determining materiality; annual Form 10-K Item 106 disclosure of risk management, strategy and governance | Audits the incident materiality determination process and the accuracy of governance disclosures |
| Revenue recognition (ASC 606; IFRS 15) | All | Five-step model; subscription, usage, multi-element and modification accounting; contract costs (ASC 340-40) | Audits the revenue and billing process and the judgments in it |
| SOC 2 (AICPA Trust Services Criteria); ISO/IEC 27001:2022 | Service organizations whose customers demand assurance; most B2B SaaS | Annual SOC 2 Type 2 examination over security (and availability, confidentiality, processing integrity, privacy as selected); ISO 27001 certification with annual surveillance | Audits the control environment the reports describe; coordinates with the service auditor; avoids becoming the SOC 2 project team |
| PCI DSS v4.0.1 | Companies storing, processing or transmitting cardholder data | Twelve requirements; annual assessment (self-assessment or qualified security assessor); future-dated requirements mandatory since 31 March 2025 | Tests scope reduction (tokenization, outsourcing) and the compliance program |
| Privacy law (GDPR; UK GDPR; US state laws, twenty by 2026; sector laws such as HIPAA where applicable) | Companies processing personal data of covered residents | Lawful basis, notices, rights handling, data protection impact assessments, processor contracts, transfers, breach notification (72 hours under GDPR) | Audits the privacy program; the data privacy audit guide |
| EU AI Act (as amended 2026) | Providers and deployers of AI systems in the EU market | Prohibitions; general-purpose model obligations (since August 2025); transparency (from August 2026); high-risk obligations (Annex III from 2 December 2027; Annex I from 2 August 2028) | Audits AI governance and the classification of the company’s own products; the AI governance guide |
| DORA (EU, since 17 January 2025); NIS2 (EU, transposition from October 2024) | DORA: financial entities and their critical ICT providers; NIS2: essential and important entities including many digital infrastructure and service providers | ICT risk management, incident reporting, resilience testing, third-party risk, information sharing (DORA); risk management measures and incident reporting (NIS2) | Audits the ICT risk framework; DORA assigns internal audit explicit duties (the DORA guide) |
| Export controls (EAR), sanctions (OFAC) | Companies exporting software, encryption, cloud services | Classification, licensing, screening of customers and users, deemed exports | Audits screening and classification processes |
| Platform and content rules (EU Digital Services Act, UK Online Safety Act, US state laws) | Platforms hosting user content | Risk assessments, moderation processes, transparency reporting, audits for the largest platforms | Audits the compliance program; mandatory independent audits for very large platforms are external |
SaaS-specific financial risks
Revenue is the first and largest. Subscription revenue is recognized ratably over the term, usage-based revenue as usage occurs (with estimation where billing lags), professional services as performed, and multi-element arrangements (platform plus modules plus services plus support) require allocation of the transaction price on standalone selling prices; contract modifications, renewals with discounts, free periods, credits for service failures and non-standard terms negotiated by sales at quarter-end each create judgment and error. The controls sit in the quote-to-cash chain (the CPQ tool, the contract repository, the billing platform, the revenue recognition engine, the general ledger) and in the review of non-standard deals, and the audit tests contract-to-invoice-to-revenue tracing for a sample weighted to non-standard terms, the configuration of the billing and revenue engines, usage data completeness and accuracy from the product to the invoice (a metering control that finance rarely owns), and the quarter-end deal review. The revenue recognition audit guide gives the program. SaaS metrics (ARR, net and gross revenue retention, customer counts, logo churn, customer acquisition cost, lifetime value, gross margin by product) are disclosed to investors, drive compensation and are computed outside the accounting system by definitions the company wrote; the audit tests that definitions are documented and consistent across disclosures, that the computation is reproducible from source data, that changes in definition are disclosed, and that the metrics reconcile to revenue where they should. Sales compensation (commissions on bookings, accelerators, clawbacks) is the largest controllable expense after headcount and the most error-prone, with ASC 340-40 capitalization and amortization of commissions adding an accounting layer. Capitalized software (ASC 350-40 for internal-use software and the SaaS company’s own platform) requires judgments about the development stage and the hours that qualify, with engineering time records as the evidence. Cloud cost is often the largest cost of revenue, procured by engineers through consoles rather than purchase orders, and the FinOps discipline that governs it (tagging, budgets, commitments, rightsizing) is an operational audit few functions have performed. Stock-based compensation (grants, modifications, performance conditions) and the equity administration behind it round out the list; the financial close guide covers the close that pulls these together.
| Risk | Where it lives | Audit tests | Finding that recurs |
|---|---|---|---|
| Subscription and usage revenue | CPQ, contracts, billing platform, revenue engine, usage metering | Contract-to-revenue tracing weighted to non-standard terms; engine configuration; usage completeness from product logs to invoices; quarter-end deal review | Non-standard terms in order forms not captured in the billing platform; usage under-billed by metering gaps |
| Standalone selling prices and allocation | Revenue accounting policy; pricing analysis | SSP analysis refreshed; allocation re-performed on a sample | SSP ranges stale after pricing changes |
| SaaS metrics | Data warehouse; analyst spreadsheets; investor relations | Definitions documented; reproduction from source; consistency across earnings materials, the 10-K and investor decks; change disclosure | ARR definition differs between the board deck and the 10-K |
| Sales compensation | Commission platform; plans; bookings data | Plan-to-payment re-performance; clawback enforcement; ASC 340-40 amortization | Manual adjustments without approval; clawbacks never applied |
| Capitalized software | Engineering time tracking; project stage determinations | Stage determinations; hours evidence; amortization start on go-live | Capitalization of maintenance; hours estimated after the fact |
| Cloud cost | Cloud provider accounts; FinOps tooling | Tagging coverage; budget alerts; commitment utilization; orphaned resources; account ownership | 20 to 30 percent of spend untagged; unused reserved capacity |
| Stock-based compensation | Equity administration platform; board approvals | Grant approvals; modification accounting; 10b5-1 and insider trading controls | Grants recorded before board approval dates |
Product security and the engineering control environment
The engineering organization is the company’s largest control environment and the one finance-trained auditors least understand. Its controls: identity and access through a central identity provider with single sign-on and multifactor authentication, role-based and just-in-time access to production, and privileged access management (the IAM and privileged access guides); change management through version control, peer review, automated testing, pipeline gates and deployment controls, in which the pipeline is the control and the audit tests its configuration and its bypasses (the SDLC and DevOps pipeline guide); infrastructure as code and cloud configuration baselines (the cloud security and AWS guides); vulnerability management across code dependencies, containers and infrastructure, with service-level objectives for remediation (the patch and vulnerability guide); secrets management and key management; logging, detection and incident response with the SEC materiality determination process attached (the incident response guide); product security practices (threat modeling, security testing in the pipeline, penetration tests, a bug bounty program, secure defaults in the product); availability and resilience (architecture, redundancy, backup, disaster recovery testing, status communication and the service credits that outages trigger); and data governance (classification, customer data isolation in multi-tenant systems, retention and deletion, residency commitments). The customers’ auditors see this environment through the SOC 2 report, and internal audit’s work should be designed around it rather than duplicating it: the SOC 2 report describes the controls the company told its service auditor it has; internal audit tests whether they work for the risks the company faces, including the ones the SOC 2 scope excludes. The SOC 2 report review guide covers reading such reports from the customer’s side, which is the view the function should understand.
Privacy, AI and the rules that follow the product
A software product sold globally carries the privacy law of every market it enters, and a tech company’s privacy program is a cross-functional machine (legal, security, product, data engineering, customer support) whose failures surface as regulator fines, customer contract breaches and lost deals in procurement reviews. Internal audit’s privacy work tests the data inventory and processing records, the lawful basis and notice for each processing activity, the handling of data subject requests within statutory deadlines, data protection impact assessments for new features, processor and sub-processor contracts and the sub-processor list customers rely on, international transfer mechanisms, retention and deletion as actually implemented in systems (the gap between the retention policy and the databases is the recurring finding), and breach notification readiness under the 72-hour GDPR clock and the state laws. AI adds a second layer: the company is a provider under the EU AI Act for AI features in its product and a deployer for the AI it uses internally, the classification of product features against the Act’s categories is a legal exercise with dated obligations, customers ask contractually what the product does with their data in AI features, and the governance of training data, model evaluation, transparency and human oversight is the subject of the AI governance audit guide. The data privacy audit guide gives the privacy program.
The shape of a tech company’s audit universe
| Domain | Representative entities (Halberd Software, 58 in total) | Typical rating and cycle |
|---|---|---|
| Revenue and go-to-market (9) | Quote-to-cash and billing; revenue recognition judgments and the revenue engine; usage metering; SaaS metrics and investor disclosures; sales compensation; channel and partner programs; pricing and discount governance; customer contracts and non-standard terms; collections and credit | High (annual) for revenue, metering, metrics and compensation |
| Engineering and product security (12) | Identity and access to production; CI/CD pipeline and change management; cloud configuration and infrastructure as code; vulnerability and dependency management; secrets and key management; logging, detection and incident response; product security program; availability, backup and disaster recovery; multi-tenant data isolation; open source license compliance; engineering capitalization time records; AI features in the product | High (annual) for access, pipeline, cloud, incident response, isolation and AI features |
| Privacy and compliance (8) | Privacy program and data inventory; data subject requests; sub-processors and transfers; retention and deletion; SOC 2 and ISO 27001 program governance; PCI DSS scope; export controls and sanctions screening; regulatory change management (AI Act, state laws) | High for the privacy program, retention and SOC 2 governance |
| Finance and SOX (10) | ICFR program; financial close; stock-based compensation and equity administration; capitalized software; cloud cost and FinOps; procurement and accounts payable; payroll (global, with contractors); treasury and cash; tax (sales tax on SaaS, transfer pricing, R&D credits); disclosure controls and the SEC cyber disclosure process | ICFR, close and disclosure High; others two years |
| People and corporate (8) | Hiring and background checks; onboarding and offboarding (access); contractor management; compensation and equity grants; code of conduct and ethics hotline; insider trading policy; corporate IT (endpoints, SaaS applications, identity); facilities | Offboarding and corporate IT High; others two to three years |
| Strategy and governance (6) | Board and committee governance; ERM; acquisitions and integration; third-party and vendor risk; AI governance; business continuity | Acquisitions and third-party High; others two years |
| Customer and operations (5) | Customer support and data access by support staff; implementation and professional services; customer success and renewals; status communication and service credits; trust center and security questionnaire responses | Support access High; others two years |
Agile methods that fit the culture
The function that succeeds in an engineering culture adopts some of its habits without surrendering its standards. Engagements are scoped small and shipped fast: a two-to-four-week sprint on one risk (production access for one platform team; the usage metering of one product line) with findings delivered as they are confirmed rather than held for a report, and the formal report following in days. Evidence is pulled from systems rather than requested from people: identity provider exports, pipeline logs, cloud configuration snapshots, ticketing data, with the auditor’s scripts kept and rerun (the SQL for auditors guide is the entry skill). Findings are written as engineers read them: the condition, the evidence, the risk in the product’s terms, and a fix the team can put in a backlog, tracked in the same ticketing system the teams use rather than a separate audit log; the writing recommendations guide applies with the vocabulary changed. Continuous assurance replaces some point-in-time testing: automated checks on access, configuration and change that run monthly and alert the function and the owning team (the continuous auditing guide), which also serves the SOC 2 and SOX programs. And the function speaks at engineering forums, publishes its plan on the internal wiki and treats a declined finding as a conversation rather than an escalation, until it must be one. The Standards’ requirements (planning, evidence, documentation, supervision, communication) are met in all of this; what changes is cadence and form. The methodology manual guide shows where the sprint format fits in a written methodology.
What goes to the audit committee
A tech company’s audit committee is often new to the role and heavily occupied with SOX, revenue and the external audit, and the function’s reporting should make the rest visible: the risk-based plan with the share of hours outside SOX, product security and resilience results in business terms, the privacy program’s status against the regulatory calendar, the metrics assurance results, the SEC cyber disclosure process’s operation (incidents assessed and determinations made), AI governance, acquisition integration, and the status of SOC 2 and ISO findings the customers’ auditors raised. The audit committee charter and annual agenda guides give a committee its structure, and the board risk reporting guide the risk pack a company that has outgrown its founders’ instincts should be building.
Careers and pay in tech internal audit
Tech functions hire IT auditors with cloud and security skills (CISA, CISSP, cloud certifications), SOX specialists from large firms, data-literate auditors who can query warehouses, and, for revenue, accountants who know ASC 606; the CIA is valued less than in other industries and the technical credentials more, and the CISA for internal auditors guide describes the path. Pay is the highest of any industry for comparable roles, with equity compensation that can exceed salary at a company whose stock performs, and the salary guide‘s ranges should be read as floors; the trade is volatility (functions shrink in downturns, and the 2022 to 2023 layoffs reached internal audit) and the small size of most functions, which limits progression inside them. Exit paths run to security and GRC leadership, finance operations, product operations and the compliance roles that privacy and AI regulation are creating, and the function’s visibility across the whole company makes it a common route into chief of staff and operations roles. The exit opportunities guide covers the general map.
Failures that recur
| Failure | How it shows | What the function should do |
|---|---|---|
| The SOX-only function | Three years after the IPO, 80 percent of hours on ICFR; no operational audit ever | Risk-based plan with a stated non-SOX share; co-source SOX testing to free the team |
| Auditing around the stack | Access tested by interview; pipeline controls accepted from a policy | Hire or build the skills; pull evidence from systems |
| Metrics unaudited | ARR definitions differ across documents; a restatement of a non-GAAP metric | Metrics assurance as a standing High entity |
| Metering invisible | Usage revenue depends on product logs nobody in finance has seen | Audit the metering control chain from product to invoice |
| SOC 2 as the security program | The company believes its SOC 2 report; the breach comes through something out of scope | Test the environment for the company’s risks, including out-of-scope systems |
| Privacy policy versus databases | Retention policy says two years; the data warehouse holds everything | Test deletion as implemented |
| Culture capitulation | Findings softened to avoid friction; declined findings never escalated | Evidence-based findings in the teams’ language; escalation path used when needed |
| Acquisitions unintegrated | Acquired products running on their own stacks and controls two years later | Integration audits within twelve months |
| Cloud cost nobody owns | Largest cost of revenue procured through consoles with no tags or budgets | FinOps audit; account ownership |
A worked example: Halberd Software’s pre-IPO function
Halberd Software, Inc., the B2B software company used in the technology examples on this site, sells a subscription workflow platform with usage-based add-ons to about 3,100 customers; it had $310 million of annual recurring revenue, 1,400 employees in four countries, two acquired products on their own infrastructure, a SOC 2 Type 2 report and ISO 27001 certification when its board decided in early 2025 to prepare for a listing in the second half of 2026. The first chief audit executive, a former large-firm senior manager with SOX and cloud audit experience, joined sixteen months before the target date, negotiated functional reporting to the audit committee chair-designate and a charter before the first board meeting, engaged a national firm for SOX readiness under a capped time-and-materials arrangement, and hired three auditors (cloud security, data analytics, revenue accounting) over the following six months. The function’s first year, below, shows the sequence and the trap it was designed to avoid.
| Engagement (hours) | What it found | Outcome |
|---|---|---|
| SOX readiness (4,800, of which 3,600 co-sourced) | Materiality set at $3.1 million; 24 significant accounts; 142 key controls; 9 in-scope systems; design gaps in revenue (non-standard terms review), stock compensation (grant date approvals) and ITGCs for one acquired product’s stack | Design gaps remediated over two quarters; operating effectiveness testing clean before the listing; the acquired stack migrated rather than brought into scope |
| Usage metering and billing (420) | Metering events from the product’s event stream to the billing platform: 2.3 percent of usage events for one add-on dropped by a queue timeout and never billed, about $1.9 million a year; no reconciliation existed between product usage and billed usage | High; queue fixed; a daily usage-to-billing reconciliation built and owned by finance; revenue recovered prospectively |
| SaaS metrics assurance (360) | ARR computed in the data warehouse by one analyst’s scripts; three definitional inconsistencies between the board deck and the draft prospectus (treatment of multi-year prepaid deals, of customers in notice period, and of professional services bundles); the computation reproduced from source after corrections | High; metrics definitions document adopted by the disclosure committee; a second reviewer; the prospectus and future filings consistent |
| Production access and identity (480) | Single sign-on and MFA enforced; 61 standing production administrator roles across 38 engineers where just-in-time access was the policy; 14 offboarded contractors with active cloud credentials | High; standing admin roles cut to 9 break-glass accounts; contractor offboarding automated from the HR system |
| CI/CD pipeline change controls (400) | Peer review enforced on protected branches; pipeline bypass permission held by 22 engineers and used 310 times in a quarter, mostly for hotfixes, with no after-the-fact review | Medium; bypass permission narrowed to on-call leads; bypass review added to the weekly change report |
| Privacy: retention and deletion (300) | Retention schedule published to customers promised deletion of customer data 90 days after contract end; the data warehouse and two backup systems retained it indefinitely; 31 former customers’ data present | High; deletion implemented across systems; sub-processor list updated; legal reviewed the customer commitment |
| Cloud cost (FinOps) (240) | Cloud spend was 31 percent of cost of revenue; 27 percent of resources untagged to a product or team; committed-use coverage at 54 percent; 1,900 orphaned storage volumes | Medium; tagging policy enforced through the pipeline; commitments increased; $2.6 million annualized savings identified by the engineering team’s own follow-up |
| SEC cyber disclosure process design (160) | Incident severity scale existed; no process for the materiality determination the 8-K rule requires or for who decides within four business days | Process designed with legal and the disclosure committee; tabletop exercise run before the listing |
The function listed the company with the SOX program clean and 42 percent of its first-year hours outside SOX, and the audit committee’s first annual review of the function recorded that the metering and metrics engagements had changed the prospectus and the retention finding had changed a customer commitment. The CAE’s observation was the one this guide makes: the readiness program was the reason the function existed and would have consumed it entirely, and the three technical hires were what made the rest possible. The pre-IPO SOX readiness guide covers the program in depth and the revenue recognition audit guide the revenue work.
A worked example: Helder Payments’ DORA year
Helder Payments B.V., the Dutch payment institution used in examples across this site, is a technology company in a regulated wrapper: licensed and supervised in the Netherlands, processing payments for online merchants on a platform its engineers build and run, and in scope of the EU’s Digital Operational Resilience Act from 17 January 2025. DORA assigns internal audit explicit duties (the ICT risk management framework is subject to internal audit review by auditors with sufficient knowledge, with findings tracked and reported), and Helder’s function performed its first DORA audit over 320 hours, finding seven issues of which four were High, including a register of information that listed 38 ICT third-party arrangements where the audit identified 57, as the DORA guide describes. For this guide the point is the pattern it shares with Halberd: the regulated and the unregulated tech company both failed first on inventory (third-party arrangements at Helder; production accounts and untagged cloud resources at Halberd), both found their controls lived in configuration their auditors had to learn to read, and both found that the program that founded or framed the function (DORA at Helder, SOX at Halberd) was the floor of the plan rather than its ceiling. The cyber resilience audit and third-party risk management guides cover the two areas Helder’s year turned on.
Questions about internal audit at tech companies
When should a tech company start an internal audit function?
Fifteen to eighteen months before an expected IPO, so that SOX readiness can run through two closes and the function exists beyond SOX before the listing. Private companies with regulated activities (payments, lending, health data), large enterprise customers demanding assurance, or boards asking for independent assurance start earlier.
What does internal audit do at a SaaS company?
It runs or supports the SOX program, audits revenue and usage billing, the SaaS metrics investors rely on, sales compensation, capitalized software and cloud cost; tests the engineering control environment (production access, pipeline change controls, cloud configuration, vulnerability management, incident response, data isolation); audits the privacy and AI governance programs; and reports to the audit committee on all of it.
How is tech internal audit different from other industries?
Controls live in systems and code rather than approvals, so the function needs IT, security and data skills; the product itself is the largest risk; investors value non-GAAP metrics nobody else audits; the culture resists documentation; and the function is usually founded late and fast for an IPO, which makes the SOX-only trap its most common failure.
Does a SOC 2 report replace internal audit?
No. A SOC 2 report describes the controls the company told its service auditor it has, for the systems and criteria in scope, for customers’ use. Internal audit tests whether the control environment works for the company’s own risks, including systems and risks outside the SOC 2 scope, and reports to the board.
What skills does a tech internal auditor need?
Cloud and identity concepts, the ability to read pipeline and infrastructure configuration, data querying skills, security fundamentals (CISA, CISSP or cloud certifications help), and for the finance side ASC 606 revenue accounting. The ability to write findings engineers will act on matters as much as any credential.
What are the SEC’s cybersecurity disclosure requirements?
Since December 2023, registrants must disclose a material cybersecurity incident on Form 8-K within four business days of determining it is material, and describe their cybersecurity risk management, strategy and governance annually in the 10-K. Internal audit tests the materiality determination process and the accuracy of the governance disclosures.
Related guides
- Pre-IPO SOX readiness — the program that founds most tech functions.
- How to establish an internal audit function — founding a function in general.
- Your first 90 days as CAE — the charter and reporting line negotiation.
- How to audit revenue recognition — subscription and usage revenue.
- Building the IT audit plan — the technology coverage at the core.
- SDLC and DevOps pipeline audit — the pipeline as the control.
- Cloud security audit program — configuration and infrastructure as code.
- IAM audit — identity and production access.
- Incident response audit — the response and the SEC materiality clock.
- SOC 2 report review — what the customers’ auditors see.
- Data privacy audit — the privacy program.
- Auditing AI governance — the product’s AI and the EU AI Act.
- DORA for internal auditors — Helder Payments’ regulated frame.
- Continuous auditing — automated assurance over access and configuration.
- SQL for auditors — pulling evidence from systems.
- CISA for internal auditors — the technical credential path.
- Internal auditor salary guide — pay, with tech at the top.
- Standing Up Internal Audit After an IPO: The First 18 Months — the first 18 months: charter, plan, staffing, SOX and the committee.
- Auditing Agentic AI: Authority, Logging and Kill Switches — authority limits, identities, logging, kill switches and prompt injection tests.
Leave a Reply