Frequently asked questions.

A purchase price allocation, or PPA, is the process of spreading the total price you paid for an acquired business across everything you actually bought. You value each identifiable asset and liability at fair value on the acquisition date — including intangibles like customer relationships and technology — and assign whatever you paid above the net of those fair values to goodwill. It is required under ASC 805 and IFRS 3.

Both use the acquisition method, so the overall approach matches. They diverge on details: ASC 805 requires noncontrolling interest at full fair value, while IFRS 3 lets you choose fair value or a proportionate share of net assets. Impairment testing also differs, with US GAAP working at the reporting-unit level and IFRS at the cash-generating-unit level. We reconcile both if you report under each.

Goodwill is the residual. You start with the total consideration you transferred, add any noncontrolling interest and previously held interest measured as the standard requires, then subtract the fair value of the identifiable net assets you acquired. Whatever remains is goodwill. Because it falls out of every other measurement, an error anywhere in the allocation flows straight into your goodwill balance.

Any intangible that is either separable or arises from contractual or legal rights gets recognized apart from goodwill. In practice that usually means customer relationships, developed technology, trademarks and trade names, order backlog, and noncompete agreements. Each is valued with a method suited to how it earns — excess earnings for customer relationships, relief from royalty for technology and brands. Isolating them keeps your goodwill honest.

It applies if you are a for-profit business that does business in California, collects California consumers’ personal information, and meets one of three thresholds: over 25 million dollars in annual revenue, data on 100,000 or more consumers or households a year, or 50 percent or more of revenue from selling or sharing personal information. You do not need a California office to qualify — serving California consumers online is enough. Our assessment confirms exactly where you stand.

They are not two separate laws. The CPRA, passed by California voters in 2020 and effective in 2023, amended and expanded the original CCPA. The operative statute today is the CCPA as amended. The CPRA added the rights to correct data and to limit sensitive personal information, created the "sharing" concept for behavioral advertising, and established the California Privacy Protection Agency as a dedicated enforcer.

Selling means disclosing personal information to a third party for money or other value. Sharing, a CPRA concept, means disclosing it for cross-context behavioral advertising even when no money changes hands. Both trigger opt-out rights and the "Do Not Sell or Share My Personal Information" link. Many companies assume they do not sell data, then find during data mapping that an advertising or analytics partner qualifies as a third party.

A service provider processes personal information on your behalf, for purposes you set, under a contract that bars other uses; disclosing data to one is not a sale. A contractor is similar. A third party is anyone who is neither, and handing data to a third party for their own use generally counts as selling or sharing. The label decides your contract terms and your opt-out obligations, so getting it right matters.

It is the split of security duties between you and your cloud provider. The provider secures the underlying infrastructure — data centers, hardware, and core services. You secure everything you configure on top: accounts, permissions, network rules, storage settings, and encryption. The exact line shifts by service, but the customer side is where most breaches happen. A cloud security review checks that you have held up your end.

A cloud security review inspects how your environment is configured — identity, network, storage, encryption, and logging — against CIS Benchmarks and provider guidance. A penetration test actively attacks a running system to find exploitable weaknesses. They catch different problems, so most mature teams run both: the review finds the open door, the penetration test proves what an attacker could do once through it.

Yes. We run cloud security reviews across all three major providers, and against multi-cloud environments that mix them. The core principles are the same everywhere — least privilege, network segmentation, encryption, and logging — but each platform names and configures them differently. We benchmark each account against CIS and the relevant provider guidance, so the review fits the cloud you actually run.

No. We work from a scoped, read-only role that lets us inspect configuration without changing anything or touching your workloads. We read settings; we do not exploit them or run active attacks. That is a deliberate difference from a penetration test. Your engineers keep shipping while we review, and nothing in your environment changes as a result of our access.

CMMC 2.0 has three levels tied to data sensitivity. Level 1 (Foundational) covers 17 basic practices for contractors handling only Federal Contract Information. Level 2 (Advanced) requires all 110 controls of NIST SP 800-171 for those handling Controlled Unclassified Information. Level 3 (Expert) adds a subset of NIST SP 800-172 for the most critical programs. Your required level is set by the contract you are pursuing.

No, and we are clear about that. FinAudit CPA provides CMMC readiness: the gap assessment, System Security Plan, POA&M, and remediation support that get you prepared. Only an authorized C3PAO can conduct a certification assessment for Level 2, and government teams assess Level 3. We prepare you for that assessment, then support you through it, but the certification decision is not ours to make.

A self-assessment is one your own organization performs and attests to, allowed for Level 1 and for some Level 2 contracts. A C3PAO assessment is conducted by a Certified Third-Party Assessment Organization independent of you, required for most Level 2 contracts and effectively for anything handling sensitive CUI. Level 3 goes further and is assessed by the government. The contract tells you which path applies.

CMMC does not invent new controls; it verifies the ones already in federal standards. Level 2 maps directly to the 110 controls in NIST SP 800-171, which defense contractors have technically been required to meet for years under DFARS. Level 3 keeps those and adds a subset of the enhanced controls in NIST SP 800-172. CMMC is the assessment mechanism that puts teeth behind those existing requirements.

Yes, in most cases we see. GDPR applies to any organization that offers goods or services to people in the EU or monitors their behavior, regardless of where the company is based. A US firm with EU users, EU-facing marketing, or analytics that track European visitors falls inside the regulation. Having no European office does not exempt you, so the real question is how large your compliance gap is.

GDPR requires a valid legal reason for every use of personal data. The six lawful bases include consent, contract, legal obligation, vital interests, public task, and legitimate interests. You must pick and document the right one for each activity before you process the data. If you cannot point to a lawful basis, the processing is unlawful, which is one of the first things a regulator checks.

A record of processing activities documents what personal data you handle, why, who you share it with, where it goes, and how long you keep it. GDPR requires most organizations to maintain one. It is often the first document a regulator asks for, because it shows whether you actually understand your own data. Our assessment reviews your ROPA for completeness or helps you build it from your data map.

A DPIA is required when a processing activity is likely to create a high risk to people, such as large-scale profiling, systematic monitoring, or handling sensitive data at scale. It documents the risk and how you reduce it. Many companies skip DPIAs they legally owe. Our assessment flags the high-risk activities in your environment that require one so you can close the gap.

No. There is no official government HIPAA certification, and no federal agency issues a "HIPAA certified" seal. Any vendor claiming to hand you a government certificate is misreading the law. What exists is a compliance assessment and attestation: FinAudit CPA assesses your safeguards and Security Risk Analysis against the HIPAA rules and documents where you stand. That documented evidence, not a badge, is what your healthcare customers actually accept.

A HIPAA security risk assessment, or Security Risk Analysis, is the accurate and thorough evaluation the Security Rule requires of the risks to the confidentiality, integrity, and availability of the ePHI you hold. It identifies threats and vulnerabilities across your administrative, physical, and technical safeguards and rates each risk. Regulators treat a missing or shallow risk analysis as the most common HIPAA failure, so we make it the anchor of every engagement.

Covered entities — health plans, clearinghouses, and providers that bill electronically — must comply, and so must business associates. A business associate is any company that creates, receives, maintains, or transmits PHI for a covered entity. If your software touches patient data for a healthcare customer, you are almost certainly a business associate, and since HITECH you are directly liable under the Security Rule for your own compliance.

A covered entity delivers or pays for care directly, such as a hospital, clinic, or insurer. A business associate provides a service to a covered entity that involves PHI, which describes most health-tech SaaS. The covered entity gives patients a Notice of Privacy Practices; the business associate signs a Business Associate Agreement. Since HITECH, both carry direct HIPAA liability, so being "just the vendor" no longer shields you.

ISO 22301 is a certification. An accredited certification body audits your business continuity management system against the standard and, if you meet the requirements, issues a certificate that outside parties recognize. That is different from SOC 2, which is an attestation report signed by a CPA firm. With ISO 22301 the deliverable your customers see is the certificate, backed by the audit that produced it.

A business impact analysis identifies your critical activities and measures what happens, over time, when each one stops. It tells you which functions you must restore first and how much downtime or data loss you can tolerate. That analysis drives everything else in the BCMS, including your recovery objectives and continuity strategies, so a weak one undermines the whole system. We run it with your teams so the numbers reflect real consequences.

Recovery time objective (RTO) is how quickly you must restore a critical activity after a disruption. Recovery point objective (RPO) is how much data, measured in time, you can afford to lose before recovery. If your RPO is 1 hour, you need backups no older than an hour. These targets come out of the business impact analysis and set the bar your continuity strategies have to meet.

A disaster recovery plan restores technology: systems, data, and infrastructure. ISO 22301 protects the whole organization, including people, processes, and suppliers, with technology recovery as one part. Disaster recovery answers how you bring the systems back. ISO 22301 answers how the business keeps its critical operations running and recovers the rest. Disaster recovery is often a component inside a certified continuity management system.

ISO 9001 is a certification. An accredited certification body audits your quality management system against the standard and, if it holds up, issues a certificate valid for 3 years. That is different from a SOC 2, which is an attestation report a CPA firm writes rather than a pass-or-fail certificate. With ISO 9001, you get a mark you can display and cite in tenders.

It depends on where you start. A firm with orderly processes can often reach the certification audit in a few months, while one building its quality system from scratch should plan for longer. The standard expects the system to have actually operated and produced evidence before the auditor arrives, so real running time, not paperwork speed, sets the timeline.

Cost depends on your size, the number of sites, how complex your processes are, and how mature your current way of working is. Remember there are two parts: our fee for building and preparing the system, and the accredited certification body's separate fee for auditing it. We scope both transparently and quote our work as a fixed fee, so you avoid surprise hourly bills.

ISO 9001 manages the quality of what you deliver, so procurement teams and tender panels ask for it. ISO 27001 manages the security of the information you hold, so security and IT teams ask for it. Both are ISO management-system standards with a shared structure, and many organizations hold both because different buyers worry about different risks.

No, though they are closely related. ITIL is a library of good-practice guidance for IT service management that you choose how far to adopt. ISO 20000-1 is a certifiable international standard your organization can be audited and certified against. Most teams use ITIL as the detailed how-to and ISO 20000-1 as the certificate that proves an independent auditor confirmed they actually run that way.

No, and no credible preparer should. The accreditation rules that give the certificate its value require the certification body to be independent of whoever built your system. FinAudit CPA prepares your service management system, runs the readiness review, and performs the internal audit. An accredited certification body then performs the formal Stage 1 and Stage 2 audits and issues the certificate, which is what makes it trustworthy to your clients.

It depends on where you start. A team with mature, documented, ITIL-aligned processes can often reach the certification audit in a few months. A team building much of the system for the first time should plan for longer, because the standard expects the system to have operated for a period before an auditor can confirm it works. We give you a realistic schedule at scoping rather than an optimistic one.

Cost depends on the scope of your service management system, how mature your processes already are, how clean your tooling and records are, and the certification body’s own audit fees. We quote a fixed preparation fee up front, and we are transparent that the accredited body charges separately for the Stage 1, Stage 2, and annual surveillance audits based on your size and scope.

An ISMS, or information security management system, is the governing framework ISO 27001 requires — the policies, risk process, roles, objectives, and review rhythm that keep security running as a managed discipline. It is not a tool or a firewall. You define what you protect, assess the risks, decide how to treat them, and prove the system keeps improving. The certificate confirms that this system exists and works.

ISO 27001 is an international certification against a fixed standard, issued by an accredited certification body and recognized worldwide, especially outside the US. SOC 2 is a CPA attestation report against the Trust Services Criteria, read mostly by US buyers. The underlying controls overlap heavily, so many companies hold both. Which you need first usually depends on where your customers sit.

For most companies starting from a light control base, roughly 4 to 9 months. The limit is not the audit itself but the operating history the standard demands: your ISMS has to run long enough to produce a completed risk assessment, an internal audit, and a management review before the certification body can examine it. Stronger existing controls shorten preparation, but you cannot skip the operating period.

No, and we are direct about that. ISO 27001 certificates are issued only by accredited certification bodies. FinAudit CPA prepares your ISMS, runs the risk assessment and internal audit, and supports you through the audit, then works alongside an accredited certification body that performs the Stage 1 and Stage 2 audits and issues the certificate. Keeping the roles separate is what preserves the certificate's independence.

Yes. ISO 27701 is an extension of ISO 27001, not a standalone standard. You certify a Privacy Information Management System on top of a working Information Security Management System, and the certification audit assesses both together. In practice you either hold an ISO 27001 certificate already or pursue both at the same time. We often help clients certify the two together to save time and cost.

No single certificate can make you GDPR compliant, because GDPR is a law and compliance depends on your specific processing and legal basis. What ISO 27701 does is give you a structured, auditable system that demonstrates the accountability GDPR expects. Its controller and processor controls map closely to GDPR duties, so certification is strong evidence of a serious privacy program, not a legal guarantee.

A PII controller decides why and how personal data is processed; a PII processor handles that data on the controller's behalf. ISO 27701 defines separate controls for each role, mirroring the controller and processor split in GDPR. Many companies act as both, depending on the service. We help you identify where you sit for each activity so your PIMS covers the right obligations.

An accredited certification body issues the certificate, not a consultant and not FinAudit CPA. Our role is to prepare you: we run the gap assessment, help you build the privacy management system, map it to your GDPR obligations, and guide you through the audit. Keeping preparation and certification separate is deliberate, because the party that readies you should not be the party that certifies you.

ISO/IEC 42001 is the first international standard for an Artificial Intelligence Management System, published by ISO and IEC in December 2023. It gives organizations a certifiable framework for building and deploying AI responsibly, covering risk and impact management, transparency, bias and fairness, human oversight, and the full AI lifecycle. Like other ISO management standards, an accredited certification body can certify that you follow it.

An AIMS is the set of policies, roles, processes, and controls that govern how your organization builds, buys, deploys, and monitors AI. It is not software. It is the operating framework that decides who owns AI risk, how you test for bias, when a human reviews a decision, and how you monitor and retire models. ISO 42001 defines what a credible AIMS must include.

No, and no legitimate preparer does. Accreditation rules keep preparation separate from certification. FinAudit CPA prepares your AI management system and runs your readiness and internal audits. An accredited certification body then performs the Stage 1 and Stage 2 external audits and issues the certificate. That independence is exactly what gives the certificate its credibility with your customers and regulators.

ISO 27001 protects information: confidentiality, availability, and integrity of data. ISO 42001 governs the AI systems that process that information, focusing on risks security standards miss — bias, transparency, explainability, model drift, and human oversight. They share the same management-system structure and are designed to work together, so most organizations that need one eventually want both.

The NIST Cybersecurity Framework is a voluntary risk model built around 6 functions — Govern, Identify, Protect, Detect, Respond, and Recover — that any organization can use to structure its program. NIST 800-171 is a mandatory set of 110 controls that federal contractors must meet to protect Controlled Unclassified Information. The framework shapes how you think about risk; 800-171 tells you exactly which controls to build.

Any organization that stores, processes, or transmits Controlled Unclassified Information under a federal contract, usually through DFARS clause 252.204-7012. That reaches primes and subcontractors alike across the defense supply chain. If a prime passes you CUI, their flow-down obligation becomes your requirement, and you owe a self-assessment and an SPRS score whether or not you asked for the work.

SPRS is the Supplier Performance Risk System, where defense contractors post their NIST 800-171 self-assessment result. The score starts at 110, one point for each met control, and you subtract a weighted value for every control you have not met. Because some controls carry more weight, a handful of gaps can pull the number well below 110. We calculate it conservatively so it survives scrutiny.

CMMC, the Cybersecurity Maturity Model Certification, is built directly on NIST 800-171. Its main level requires the same 110 controls, but replaces self-attestation with a third-party assessment. So the 800-171 work you do now is not throwaway; it is the foundation CMMC certification sits on. We map your assessment to CMMC levels so the next step builds on this one instead of restarting.

It depends on your level and channel. Many lower-volume merchants and some service providers can validate with a Self-Assessment Questionnaire, which needs no QSA. Level 1 merchants and higher-tier service providers need a Report on Compliance, which only a Qualified Security Assessor can perform and sign. FinAudit CPA scopes your environment, readies your controls, and works alongside a QSA when a formal ROC is required.

No. FinAudit CPA is a licensed US CPA firm, not a QSA. Under PCI rules, only a Qualified Security Assessor can perform and sign a formal Report on Compliance. We provide PCI readiness, scoping, gap assessment, and remediation support, and we coordinate directly with a QSA when your validation path requires a signed ROC or attestation.

PCI DSS v4.0 organizes controls into 6 goals and 12 requirements, covering network security, protecting stored and transmitted account data, vulnerability management, access control, monitoring and testing, and an overarching security policy. Version 4.0 also introduces the customized approach, which lets mature teams meet a requirement’s objective with their own controls, backed by a documented risk analysis and evidence.

The cardholder data environment, or CDE, is every system that stores, processes, or transmits cardholder data, plus anything connected to or able to affect those systems. Scoping matters because PCI DSS applies to the whole CDE. Good network segmentation shrinks it to the smallest defensible footprint, which lowers your cost, your risk, and the effort of every requirement in the assessment.

A QoE report centers on an adjusted EBITDA bridge that walks from reported profit to normalized, sustainable earnings, with every adjustment evidenced. Around it, the report covers revenue recognition quality, a proof of cash tying earnings to bank activity, a working capital analysis with a net-working-capital peg, customer and supplier concentration, and run-rate adjustments for recent changes. Together these show what the business truly earns and what the buyer is really acquiring.

An audit gives a formal opinion on whether financial statements are fairly presented under US GAAP or IFRS, looking backward over a reporting period. A QoE is forward-looking diligence for a deal: it tests whether reported earnings are real and repeatable after close. An audit answers the board and regulators on a schedule; a QoE answers a buyer, lender, or seller in a specific transaction. Neither replaces the other.

A buy-side QoE is commissioned by the acquirer to test the seller’s number and protect the offer, focusing tightly on the risks that could change the price. A sell-side QoE is run by the owner before going to market, so they can find and explain adjustments on their own terms, defend the asking price, and avoid surprises in diligence. The analysis is similar; the audience and the goal differ.

Normalized EBITDA starts from reported earnings before interest, taxes, depreciation, and amortization, then strips out items a new owner will not carry — one-time events, owner-specific costs, and non-recurring gains — while adding back normal costs the seller ran elsewhere. The result is a cleaner run-rate figure showing what the business earns in a typical year. Because deals are priced as a multiple of EBITDA, every adjustment can move the purchase price materially.

You need a SOC 1 when your service affects your customers’ financial statements and their auditors have to rely on your controls. That covers payroll processors, payment and transaction processors, SaaS platforms carrying financial data, claims processors, and data-center providers hosting financial applications. The signal is usually a request from a customer’s auditor. Without a SOC 1, that auditor has to test your controls directly, which slows everyone down.

SOC 1 reports on controls that affect your customers’ internal control over financial reporting, so its audience is their auditors. SOC 2 reports on controls protecting customer data against the Trust Services Criteria, so its audience is security and procurement teams. Same firm, same discipline, different question: SOC 1 asks whether your service is reliable for the books, SOC 2 asks whether it is secure. Many organizations end up needing both.

A SOC 1 Type 2 report is an opinion on whether your controls were both suitably designed and operating effectively across a period, usually 6 to 12 months. Unlike a Type I, which describes control design on a single date, a Type II tests samples throughout the window to prove the controls actually ran. It is the report most customers’ auditors want, because they can rely on it for their own annual audit.

A Type I can often be issued within a few weeks once your controls are designed and documented. A Type II takes longer because the opinion has to cover an observation period, commonly 6 to 12 months of real operation. That window, not the fieldwork, sets the calendar. If a customer needs proof sooner, we often issue a Type I first and schedule a Type II covering the following period.

No. SOC 2 is an attestation report issued by a licensed CPA firm, not a certification with a pass-or-fail badge. The deliverable is a detailed report describing your controls and how well they work, which your customers read to decide whether to trust you. That is different from ISO 27001, which is a certification against a fixed standard.

The examination itself is quick once your controls are in place, but a Type II report has to cover an observation period, usually 3 to 12 months. That window, not the audit work, sets the timeline. If you need proof sooner, we often issue a Type I first and a Type II covering the following period.

Cost depends on the number of Trust Services Criteria in scope, how many systems and products you run, how mature your controls already are, and whether you need Type I, Type II, or both. We scope every engagement transparently and quote a fixed fee up front, so you never face a surprise hourly bill.

Type I examines whether your controls are designed suitably at a single point in time. Type II examines whether those same controls actually operated effectively across a period. Type I is a fast way to show progress; Type II is the report most enterprise security teams ultimately want to see.

Both reports examine the same Trust Services Criteria and end with a CPA opinion. SOC 2 includes a detailed system description, your controls, and the auditor’s test results, so it is restricted-use and changes hands under an NDA. SOC 3 strips out that confidential detail and keeps the opinion, making it a short, general-use report you can publish and share with anyone.

Yes, that is the whole point. A SOC 3 is a general-use report, so you can post it on your website, attach it to proposals, and send it to prospects without a non-disclosure agreement. It leaves out the control descriptions and test results that make a SOC 2 sensitive, which is exactly what lets you share it freely with a general audience.

In practice, yes. The SOC 3 opinion comes from the same examination that produces a SOC 2, so you generally need a SOC 2 Type II underneath it. We run one engagement that yields both the detailed SOC 2 for reviewers and the public SOC 3 for the market, so you are not paying for two separate audits.

No. A SOC 3 is a public summary, not a substitute. Enterprise security teams and procurement reviewers still ask for the full SOC 2 with its control detail and test results. Treat the SOC 3 as the version you show the open market and the SOC 2 as the version you provide to a reviewer who wants to look closely.

Start with a readiness assessment 3 to 6 months out. We map your controls against the Trust Services Criteria, run walkthroughs to find gaps, and give you a prioritized remediation roadmap. You fix the highest-risk items first, organize evidence the way the auditor will ask for it, and then run a mock audit. That sequence is how first-timers pass cleanly instead of collecting exceptions.

A readiness assessment is a private practice run you can fail safely; the audit is the graded, signed examination your customers read. Both test the same controls against the same criteria. In readiness, a gap becomes an action item on your roadmap. In the audit, that same gap becomes an exception on a permanent report, which is far more expensive to carry.

A SOC 2 gap analysis compares your current controls against the Trust Services Criteria and flags every place you fall short: missing policies, access reviews you never documented, change management that runs informally, monitoring you cannot prove happened. We score each gap by how an auditor would treat it, so you know which failures would draw an exception and which are minor cleanup.

Aim for 3 to 6 months before your target audit period begins. The assessment itself runs 2 to 4 weeks of our work, but remediation takes as long as your gaps demand, and fixed controls need time to operate before a Type II window. Starting early gives you room to close real gaps rather than papering over them under deadline pressure.

Most organizations get the best results from a quarterly cadence — 4 short campaigns a year — rather than one big annual test. Regular, varied simulations keep awareness fresh and let you watch your report rate climb and your click rate fall over time. A single yearly test tells you little, because behavior drifts back within weeks. We help you set a rhythm that builds habits without fatiguing staff.

Yes, when it is done with proper authorization. We run every engagement under a written agreement signed by an authorized sponsor, with agreed limits on channels, targets, and timing, and a documented safe word to stop any activity. We never collect real passwords in a way that exposes them, and we handle all results confidentially. The aim is to strengthen your people, so the process is built to protect them.

All three are social engineering, just on different channels. Phishing arrives by email, vishing comes through a voice call, and smishing lands as an SMS text message. Attackers pick the channel that best fits their pretext, and often combine them — a text that primes you for a call, for example. Testing across channels matters because an employee cautious with email may drop their guard on the phone.

No, and we design it specifically to avoid that. We report results as aggregate numbers by team and role, not as a list of individuals to blame. The debrief focuses on what the organization can learn and how to make reporting easier, not on singling people out. Programs that shame staff drive mistakes underground, where they cause far more harm. We build trust instead.

IT general controls, or ITGC, are the controls over the technology environment that supports financial reporting. They fall into four domains: access to programs and data, program changes, program development, and computer operations. They are not controls over a single transaction. Instead, they govern the systems themselves, which is what lets your external auditor trust the automated controls those systems run.

Application controls act on transactions inside one system, like blocking an invoice without a matching purchase order. ITGC govern the systems those application controls live in. An auditor can only rely on an automated application control if the ITGC beneath it, especially access and change management, are effective. Weak ITGC turn every automated control into a manual one the auditor must test by hand.

The PCAOB expects controls to be identified from the financial reporting risks they address, tested for both design and operating effectiveness across the period, and evidenced clearly. Auditors are expected to understand how systems produce the numbers, not just tick a checklist. We document testing to that standard so your external auditor can review and rely on it without extensive rework.

Public companies filing with the SEC must assess internal control over financial reporting under Sarbanes-Oxley Section 404, and ITGC sit underneath that assessment. Pre-IPO companies take it on ahead of going public. Audit committees oversee the work because they are responsible for the integrity of financial reporting. If your financial systems are automated, ITGC testing is part of your SOX obligation.

An audit gives reasonable assurance, the highest level a CPA offers. We test balances, examine evidence, and confirm items with third parties, then issue an opinion on fair presentation. A review gives limited assurance through analytics and inquiry of management, with no detailed testing. The review report says only whether anything came to our attention needing change. Lenders and regulators usually want an audit; smaller lenders sometimes accept a review.

A statutory audit is a financial statement audit required by law, regulation, or contract rather than chosen voluntarily. Many jurisdictions require companies above a size threshold, or in regulated sectors, to file audited statements each year. Subsidiaries of foreign parents often face a local statutory audit regardless of size. The work and the opinion are the same as any audit; the difference is that a rule, not the owners, demands it.

It depends on who is asking and why. Lenders with covenants, regulators, and most investors require an audit. Smaller lenders and some investors accept a review, which costs less. A compilation, with no assurance, suits internal use or a basic third-party request. Check the exact wording of your loan agreement or regulatory requirement before deciding, and we will confirm the right level with you before any work starts.

Once your books are closed and reconciled, audit fieldwork commonly runs 4 to 8 weeks, longer for groups with multiple entities or currencies. A review is quicker because the procedures are lighter. The biggest variable is the readiness of your records: a clean close keeps us on schedule, while a messy one adds time before real testing can begin. We plan backward from your filing deadline.

US GAAP is the accounting framework used by US companies and set by the FASB. IFRS is used across much of the rest of the world and set by the IASB. GAAP tends to be more rules-based with detailed guidance, while IFRS leans on principles and expects more documented judgment. The two agree on many outcomes but differ on specifics like lease expense, inventory methods, and how some financial instruments are classified.

It is specialist help applying accounting standards to transactions or reporting questions that are not routine. We research the issue against US GAAP or IFRS, weigh the alternatives, and write a documented position you can book and defend. Typical topics include revenue recognition, leases, complex financing instruments, and business combinations, where a wrong call is costly to unwind and a well-supported memo saves an argument with your auditor.

Yes, in both directions. We work through every material account, document each difference between the frameworks, prepare the adjusted statements, and build a conversion workbook that reconciles the two. We often do this when a company gains a new parent, closes a cross-border deal, or faces a lender or investor that reports in the other standard. Because we work in both frameworks, one team owns the whole conversion.

We apply the same 5-step model both standards share: identify the contract, the performance obligations, the transaction price, allocate it, and recognize revenue as obligations are satisfied. The judgment lives in the details of your contracts, such as bundling, variable consideration, and timing. We document how your specific arrangements map to the standard so the revenue you report can withstand audit and investor scrutiny.

A vulnerability assessment scans broadly to find and rank as many weaknesses as it can — it answers where you are exposed. A penetration test goes deep, safely exploiting the serious findings to prove what an attacker could actually reach and do. The assessment gives you breadth and coverage; the test gives you depth and proof. VAPT runs both together so you get the full picture, not half of it.

Test at least once every 12 months, and again after any significant change — a new product, a major release, a cloud migration, or a shift in your architecture. Many frameworks and enterprise customers expect an annual test as a minimum. Between full pentests, a recurring vulnerability assessment catches new exposures early, so you are not blind for a year at a stretch.

SOC 2 does not name "penetration test" as a mandatory line item, but it expects you to identify and remediate vulnerabilities and to test your controls. A pentest is the cleanest, most credible way to produce that evidence, which is why most auditors and customers expect to see one. We scope your VAPT so its findings map directly into the SOC 2 controls, giving you the report and the evidence in a single engagement.

Common targets are your external network, internal network, web applications, APIs, mobile apps, cloud environments, and wireless. You can test one of these or several in one engagement. We help you scope to what carries real risk — usually the systems that touch customer data or sit at your perimeter — so you are not paying to test things that do not matter.

A vulnerability assessment scans broadly to find and rank all known weaknesses across your networks, systems, and applications. A penetration test goes deep, trying to actually exploit a smaller set of those flaws the way an attacker would. Think breadth versus depth: the assessment gives you ongoing visibility and compliance evidence, while the pen test proves whether your defenses truly hold under a real attack. Mature programs run both.

Most organizations scan their full estate quarterly at a minimum, and run continuous or monthly scans on internet-facing and high-change systems. Cadence matters more than any single scan, because every deployment and new server can introduce a fresh flaw. We help you set a rhythm that matches your risk profile and your compliance obligations, then keep the schedule so your visibility never goes stale between checks.

An unauthenticated scan sees your systems the way an anonymous outsider would, with no credentials. An authenticated scan logs in with valid credentials and sees far more: missing patches, weak configurations, and issues invisible from outside. Authenticated scanning takes more setup but produces a far more complete and accurate picture, which is why we use it wherever the scope allows.

Every scanner produces false alarms, and chasing them wastes your engineers time. We validate each material finding by hand before it reaches your report, confirming the weakness is real and reachable in your specific environment. That validation is the difference between a raw scanner dump and an assessment your team can act on with confidence. Noise is the enemy of remediation, so we remove it.