PCAOB Inspections Themes

PCAOB Inspection Themes
Update and COSO 2013

Transition
What your external auditors are about to ask you
30 September 2014
Introductions
Matt Mabel Senior Manager, Advisory Services Risk Assurance.
Eleventh year in public accounting. Serves several Fortune 1000 public
company based out of Arizona. Participated in PCAOB and internal
quality inspections and led several internal quality initiatives.
Diana Gomes Manager, Assurance Services. Seventh year in public
accounting. Serves multiple public companies based out of Arizona.
Participated in PCAOB and internal quality inspections.
Shirley Karnos Manager, Advisory Services Risk Assurance.
Second year in public accounting and ninth year in professional services.
Serves multiple public companies based out of Arizona. Participated in
internal quality inspections.
Page 2
Agenda
Overview of PCAOB, inspection process, and recent

results
Recent IT-related PCAOB inspect
Better understanding flows of transactions, IT interfaces, and

considering all IT risks
Testing managements controls over electronic audit evidence
Testing precision of review controls
Evaluating controls over service providers (SOC reports)
Transition to COSO 2013
Page 3
Overview of PCAOB, inspection process, and

recent results
The Public Company Accounting Oversight Board (PCAOB) is a privatesector, nonprofit corporation created by the SarbanesOxley Act of 2002 to
oversee the audits of public companies and other issuers in order to protect
the interests of investors and further the public interest in the preparation of
informative, accurate and independent audit reports.
The PCAOB audits Big 4 accounting firms in calendar Q2 and Q3 each year,
and other public accounting firms in Q4. The inspection typically consists of
review of audit documentation over internal controls and substantive audit
testing over selected high risk/focus areas. The inspections typically require
1-2 weeks of on-site fieldwork. Comments can be verbal, written (does not
appear in report) or audit deficiencies (appears in public report)
EYs last publicly available inspection report (which covered the results of
reviews of 2012 audits) was released on 8/14/14
The PCAOB inspection 56 audits of public companies during 2013
28 issuers had audit deficiencies that appeared the report, 27 of which
(48% of inspections) had comments related to ICFR
Page 4
IT-related PCAOB inspection themes
Page 5
Flows of transactions, IT interfaces, and

considering all IT risks
Page 6
PCAOB inspection theme
There have been instances in inspections in which teams

have identified ineffective ITGC's over in-scope IT
systems or have not scoped in key IT systems that
process transactions within significant accounts.
Page 7
In these instances, some teams attempted to identify and

test business process controls that address the risk of an
ineffective IT system, but were unable to identify and test
enough controls, specifically front-end prevent controls
around initiation, to sufficiently address the risks.
Inspectors have challenged our conclusions that ineffective
ITGCs did not result in a significant deficiency or material
weakness, particularly when ineffective ITGCs have existed
for more than one year.
Common IT risks that need to be considered

within significant financial processes
Unauthorized initiation/authorization of transactions
Lack of segregation of incompatible duties
Reliance on IT applications or programs that are

inaccurately processing data
Potential for errors and fraud within IT applications
Inappropriate dependence on the results of computer

processing
Lack of transaction trails or loss of data
Page 8
System interface diagrams

A system interface flow chart gives a pictorial representation of the
systems that support significant business processes, including how data
flows from system to system.
System Interface flow charts provide the reader with a quick

understanding that can help us to:
assess the complexity of the IT environment
identify where application interface controls should exist (or where control
gaps do exist)
understand the inputs/outputs from systems
understand the types of electronic audit evidence generated
Understand applications and tools supporting significant process
Page 9
Example system interface diagram

Financial
Statements
A systems
interface
diagram is a key
source of
information
used to
understand a
complex and
highly
automated IT
environment
Pep+
Caesar
CDS
CDE
E2
N
B
Hyperion
HFM
K
F
EMP
G
D
OCRA
Treasury
Customer
Online
Check
Requests
Page 10
FRP
TMS
Accurate NXG
Policy
Administrative
Systems
CASH
CIMS
Cost
allocation
files
GEAC
Payroll
Files
System interface inventory

Interface
Description
CDS E2
E2 TMS
CASH E2
CIMS E2
E2 FRP
Page 11
Data Description
Interface Type
Process
Control Language
Daily CDS transactions are balanced to

check stock used. Admin and online
Flat file data set within
Cash
transactions are balanced to CDS output.
Check disbursement data
MF environments as Disbursements
CDS totals are balanced to the general
scheduled job
Checks
ledger. Error reports are reviewed and
corrections are processed.
Connect direct file
transfers as a
Bank
Weekly bank reconciliation performed by
Banking and cash information
scheduled job from
Reconciliations Accounting department.
MF to AIX directory
Flat file transfer from
Interface from CASH System to e-2 is
Windows SQL to MF
automated. All general ledger entries are
throughout day.
Cash receipts data
Cash Receipts accomplished with this interface except
Nightly batch job
for required correcting entries made
picks up flat file data
subsequent to initial processing.
to E2
Variance analysis is completed each
month. Expense Accounting, senior
Scheduled job within
EMP Cost
management (quarterly), and cost center
Cost allocation data
MF GS02 from CIMS Allocation/Acquisiti
personnel review the expenses.
to E2
on
Significant variances are explained in the
Quarterly review book.
Informatica is utilized
to read the DB2 table
Reconciliation of E2 to FRP by legal
FRP Data Load
Financial reporting data
and create an Oracle
entity (evidenced by zeroes legal entity in
from E2
table that is then
the reconciliation report)
loaded into FRP
Testing managements controls over

electronic audit evidence
Page 12
Not identifying and testing Issuer controls (either ITGC or business

process controls) to assess the completeness and accuracy of
system-generated data and reports -- electronic audit evidence or
EAE -- used in the performance of a control
Not testing completeness and accuracy of system generated data

used to select control testing samples or to support our reliance for
substantive tests
Not testing IT general controls over all applications that produce

system-generated data or reports used in the performance or a
control or in our substantive tests
Not testing appropriate controls over end-user computing solutions

used in performance of controls
Page 13
Increased focus on issuer controls over EAE

used in performance of controls
Auditor needs to better consider that the specific systemgenerated data or report is considered and testing within
IT general control testing
Report changes need to be considered within change

management testing
Controls over access and changes to reporting tools (e.g.,
Hyperion HFM, Cognos, data warehouses) need to be considered
Auditor needs to better consider controls that issuer has in

place over completeness and accuracy of underlying data
Auditor needs to better consider if system-generated data

or reports used in performance of controls are subject to
manual change, and if so the proper controls are in place
Page 14
An example of audit documentation of EAE
Better documentation
Management has designed and implemented the following
controls to support the completeness and accuracy of the PPV
report:
Controls over the
completeness and
accuracy of the
underlying data
Business process controls - Ctrl # INV # 3.1, 3.4, 3.7; P&P #

4.1, 4.2, 4.7. We walked through and evaluated the design of
the controls at B01, B03 and B04, respectively.
Changes to the PPV report are subject to the entitys ITGCs

and the completeness and accuracy of the report is
programmed within the Inventory application. We evaluated
these controls by inspecting the underlying query used to
generate the report and by clerically testing the accuracy of the
PPV report, w/o/e (refer to B03).
Effective ITGCs over the Inventory application that maintains

the PPV report and processes the underlying data. We
evaluated the ITGCs over the Inventory application at IT01
IT03 w/ps.
Controls over the

completeness and
accuracy of the
report
Controls that support
the continued
integrity of the data
and system
processing
Page 15
Data and reports supporting the performance

of internal controls
Control: The allowance for doubtful accounts reserve calculation is reviewed
by the accounts receivable manager on a monthly basis.
Application
Cash
receipts
A/R
subledger
Analysis
prepared by
the credit
manager
Sales and
trade
receivables
Page 16
A/R aging
report

Step #1: What data or reports are used in the performance

of the control?
Application
Cash
receipts
A/R
subledger
Analysis
prepared by
the credit
manager
Sales and
trade
receivables
Page 17
A/R aging
report

Step #2: Is the data or report generated by an in-scope

application?
Application
Great Plains
Cash
receipts
A/R
subledger
Analysis
prepared by
the credit
manager
Excel
Sales and
trade
receivables
Page 18
A/R aging
report

Step #3: Are ITGCs over the application or end user

computing solution that generated the data or report
effective?
Application
Great Plains - YES
Cash
receipts
A/R
subledger
Analysis
prepared by
the credit
manager
Excel - NO
Sales and
trade
receivables
Page 19
A/R aging
report

Step #4: Have we tested specific controls over the completeness and
accuracy of the underlying data? Are the controls effective?
Application
Great Plains
Cash
receipts
YES
A/R
subledger
Analysis
prepared by
the credit
manager
Excel
Sales and
trade
receivables
YES
Page 20
A/R aging
report

Step # 5: Is data or report subject to manual change?
Application
Great Plains
Cash
receipts
A/R
subledger
Analysis
prepared by
the credit
manager
Excel - YES
Sales and
trade
receivables
Page 21
A/R aging
report - NO

Extent of identification and testing of controls over key

data and reports depends on:
Importance of the data or report to the functioning of
the control
Complexity of the calculations in a spreadsheet or
manipulation of the data in the preparation of the
report
Generally, the further away from the application with
effective ITGCs, the greater the importance of controls
over the data and reports used by management
Focus on the data and reports with greater importance to
the functioning of the controls, particularly review controls,
and higher complexity of calculations not performed by the
application with effective ITGCs
Page 22
Example of controls over review of A/R aging

report and preparation of bad debt allowance
EAE = A/R Aging Report
Quantities shipped are reconciled to quantities billed (Initiation)
The invoice amount is posted automatically into the customers account
upon generation of the invoice (Recording)
The system ages invoices based on the invoice data (Processing)
On a monthly basis, the sub-ledger is posted automatically to the GL
(Processing)
An AR reconciliation is performed by the senior accountant and reviewed
for completeness and accuracy by the accounting manager (Processing)
The controller reviews the bad debt allowance calculation and approves
the adjusting journal entry on a quarterly basis (Processing)
Page 23
End-user computing solutions
End-user computing solutions likely are not subject to ITgeneral controls
Excel files
Access databases
Dynamic data warehouse reporting tools
System-generated data in slide decks
Need to better consider issuer controls over end-user

computing solutions
Input
control the company reconciles data back to source documents

Access control Access is restricted to authorized personnel and is
password protected
Version control Standard naming conventions are in place so only
current and approved versions are used
Page 24
Testing precision of management review

controls
Page 25
Beyond verifying that the control occurred (e.g., evidence of

signature) there was no evaluation of the review controls
effectiveness and level of precision
Cannot rely on absence of exceptions from substantive review as

evidence controls are operating effectively (controls need to be tested
directly)
Our evaluation of review controls should consider all evidence of their
precision, sensitivity and ability to detect significant
errors/misstatements
Verifying existence of managements signature, by itself, does not test
operating effectiveness
Our evaluation of review controls should consider how management
identified errors/issues in the review and how the ensure that those
errors/issues are resolved
Often related to financial controls (e.g., non-routine transactions like

business combinations), but can impact IT general controls as well
Page 26
Example periodic access review
Test of control bad example:
Obtained evidence of review, saw review was signed off and some
updates were noted in the review listing
Test of control good example:
Page 27
Inquired with individual(s) performing review to understand how they

review and identify errors/exceptions
Obtained understanding of how access reports were generated and how
reviewer knows listings are complete
Observe the performance of the review
For each review tested, confirm the review was signed off
For each review tested, traced a sample of updates requested through to
updated system access
For each review tested, considered significant instances of inappropriate
access identified and their impact on the overall control environment
Evaluation of controls at service providers

(SOC reports)
Page 28
Reliance on service organizations was either not identified or not appropriately

documented to determine whether the service auditors report provided sufficient audit
evidence about the effectiveness of relevant controls
Sub-service organizations that were scoped out of the report were not addressed (i.e.,
SOC 1 report was not obtained and there was no documentation of considerations and
conclusion if such sub-servicers were deemed insignificant or not relevant)
Complementary entity user controls were either not sufficiently tested, or were not
properly linked to engagement team testing of user controls that would address the
relevant considerations
Update procedures were not properly performed or documented when the service
auditors report did not sufficiently cover the entire audit period
Control exceptions identified by the service auditor were not evaluated to determine
whether sufficient audit procedures to support our combined risk assessments were still
appropriate to prevent or detect potential misstatements
Page 29
Why do we review SOC reports?
Many entities outsource aspects of their business to service

organizations that provide services ranging from performing a specific
task under the direction of the entity to replacing an entitys entire
business unit or function. These services are relevant to the audit
when these services, and the controls over them, are part of the
entitys information system relevant to financial reporting (e.g., if
the client uses electronic audit evidence from a third-party
provider as part of a control activity).
If we plan to place reliance on controls at the service organization, we

ordinarily obtain and review a service auditors report (SOC 1)
covering a sufficient portion of the audit year (this includes subservice providers of those organizations).
We review the SOC 1 report and document our evaluation of the

service provider and their impact on the audit.
Page 30
Sub-service organizations
Service providers relevant to our audit may outsource part

of their processes/controls to another third party, called a
sub-service provider
Can be part of transaction processing (e.g., claims processing)

Can be part of IT environment (e.g., data center hosting)
The service organization will identify sub-service providers

in their assertion, and the service auditor will identify subservice providers in their opinion (these should be the
same)
We must evaluate the audit impact of all identified subservice providers (including IT sub-service providers) in
our documentation
Page 31
Complementary User Entity Controls

(CEUCs)
Controls at the service provider alone do not ensure the accuracy of

our clients financial statements, and the SOC 1 report will outline
control considerations for user (our client) of the service
For each CEUC, we should evaluate if the CEUC is relevant (e.g.,
does the CEUC directly impact financial reporting risk(s) that we have
identified that the service providers controls help mitigate?)
For IT-related CEUCs, IT specialists should be used and consider the
clients responsibilities in things like user access administration (e.g.,
who has access to transmit data to the service provider for
processing) and testing/approving program changes from provider
For each CEUC deemed relevant to the financial reporting risk(s) that
were identified, we must demonstrate that the client has the
appropriate controls in place and we have tested the operating
effectiveness of those controls (e.g., these controls should be defined
as key SOX controls)
Page 32
Evaluating time period of the report and gap

between year-end
Generally, to rely on a SOC 1 report, the report must cover at least six months
of our audit period. If the report covers less than six months and a second
report is not available, we must consider/document how we are comfortable
relying on the report with a smaller coverage period (and expect to be
challenged on this).
At minimum, consider what controls are in place at the user entity that gives us
comfort that the clients internal controls would detect a material misstatement
made by the service provider if there is a large gap between the report end date
and our clients year-end date. The clients controls must be sufficiently precise.
If there is a gap larger than three months between the report end date and our
clients year-end date, we again must document our considerations of how we
are comfortable relying on the report with a large time period gap (and expect
to be challenged on this).
Page 33
At minimum, bridge letters should be obtained; but we should challenge if a bridge

letter alone is sufficient and how else the client gets comfortable over the service
providers control environment (e.g., client controls over the reports/data).
Evaluating control exceptions
The service auditors section of the report will summarize the test of controls
performed and results of controls testing. Exceptions (often called deviations)
will be noted in this section.
Auditor should evaluate all relevant exceptions noted in review

documentation
All exceptions relevant to control objectives that mitigate identified financial

reporting risks should be evaluated
Exceptions related to ITGCs supporting relevant applications that mitigate identified
financial reporting risks should be evaluated
The exceptions should show an appropriate amount of evaluation of the risk

of the exception. A blanket This exception has no impact on our audit
approach is generally not sufficient and could lead to increased scrutiny
during a quality inspection.
Page 34
Evaluating SOC reports other

considerations
Management should review/evaluate SOC reports as part

of their testing of controls for managements opinion on
their internal controls over financial reporting
PCAOB appears to have a list of problem reports, and

will challenge how teams addressed these problem
reports when used in the audit of an issuer
Some chatter on PCAOB auditing service auditors who

issue SOC reports in the near future
Page 35
Application controls
Page 36
Application controls - Testing without understanding the design
We did not demonstrate our knowledge of whether the application control was
configured by the entity or embedded into the system
If the control is configured, we did not gain/demonstrate our knowledge of how
the entity configured the control (e.g., is the three way match control configured
with a tolerance of 10% receiving variance)
Some teams did not document their considerations around which application
controls need to be re-tested in the roll forward period
Lack of evidence regarding the identification and

understanding/walkthrough of application controls, as well as
insufficient testing of application controls, including inappropriate
benchmarking procedures, inappropriate reliance on test of one
transaction, lack of consideration of managements ability to override
the automated control or insufficient evaluation of the effect of
ineffective ITGCs on the audit of application controls
Page 37
Other IT-related inspection themes
Page 38
Multi-location scoping
Controls over pricing in revenue
Consideration should include commonality of IT systems at the

locations subject to multi-location scoping
Should ensure alignment with Assurance on scope of testing of decentralized applications (e.g. Point of Sale, Revenue applications)
subject to multi-location scoping
In certain instances, specifically when significant revenue systems
are not subject to testing or are deemed ineffective, engagement
teams have not identified sufficient controls that address pricing,
quantities sold and the related extension (P x Q).
Inventory cycle counting
Page 39
Failure to test cycle count configuration (logic for A/B/C

completeness, cycle count reports)
Transition to COSO 2013
Page 40
Original framework (1992)

Designed to
Establish a common definition serving the needs of different parties

Provide a standard against which business and other entities could
assess their control systems
Control activities
Unit B
Information &
communication
Unit A
Monitoring
Risk assessment
Control environment
Internal control is defined as a process, effected by an entity's people,

designed to accomplish specified objectives.
Page 41
COSO 2013
Activity 2
Activity 1
Why the update?
COSOs Internal Control Integrated Framework (1992 edition)
Refresh
objectives
Address significant
changes to the
business environment
and associated risks
Enhancements
Updated, enhanced
and clarified
framework
Codify criteria to use in

the development and
assessment of systems
of internal control
Principles
Point of
Focus
Increase focus on
operations, compliance
and nonfinancial
reporting objectives
Expanded internal
and nonfinancial
reporting guidance
COSOs Internal Control Integrated Framework (2013 edition)
Page 42
COSO 2013
In the 2013 update, much remained the same
The cube!
Five components of internal control
The core definition of internal control
Requirement to consider the five
components to assess the
effectiveness of a system of
internal control
Emphasis on the importance of management judgment
in designing, implementing, and conducting internal
control, and in assessing the effectiveness of a system
of internal control
Page 43
COSO 2013
One of the big changes in the 2013 Framework

Principles-based approach
While the 1992 version implicitly reflected the core principles of
internal controls, the 2013 version explicitly states 17 principles that
represent the concepts associated with each of the five components
The new framework presumes that all 17 principles must be
present and functioning in an effective system of internal
control
Page 44
COSO 2013
17 principles defined
1. Control
environment
1. Demonstrates commitment to integrity and ethical values

2. Board of Directors demonstrates independence from management
and exercises oversight responsibility
3. Management, with Board oversight, establishes structure, authority
and responsibility
4. The organization demonstrates commitment to competence
5. The organization establishes and enforces accountability
2. Risk assessment
6. Specifies relevant objectives with sufficient clarity to enable

identification of risks
7. Identifies and assesses risk
8. Considers the potential for fraud in assessing risk
9. Identifies and assesses significant change that could impact
system of internal control
3. Control activities
10. Selects and develops control activities

11. Selects and develops general controls over technology
12. Deploys through policies and procedures
4. Information &
communication
13. Obtains or generates relevant, quality information

14. Communicates internally
15. Communicates externally
5. Monitoring
16. Selects, develops and performs ongoing and separate evaluations

17. Evaluates and communicates deficiencies
Page 45
COSO 2013
Principles
in the
framework
Points of focus also provided
Control
Environment
Component
Principle 1: The organization demonstrates a

commitment to integrity and ethical values
Points of focus:
Sets the tone at the top

Establishes standards of conduct
Evaluates adherence to standards of conduct
Addresses deviations in a timely manner
Points of focus are important characteristics of principles

Some points of focus may not be suitable or relevant, and others may be
identified that may be relevant
Points of focus may facilitate designing, implementing and conducting internal
control, and assessing whether the principles are present and functioning
While there is no requirement to separately assess whether points of
focus are in place, we think that is the best (and potentially only) way to
determine whether the objectives of the principles are achieved
Page 46
COSO 2013
COSO 2013
Other key changes
Specific risk assessment principle related to fraud
Specific information and communication principle related

to information quality
Principle 8: The organization considers the potential for fraud in

assessing risks to the achievement of objectives
Principle 13: The organization obtains or generates and uses

relevant, quality information to support the functioning of
internal control
Increased discussion of the effect of other organizations

(e.g., other business models, joint ventures, service
organizations)
Page 47
Management retains responsibility for controls
COSO 2013
Deficiency evaluation
An effective system of internal control requires that:
Each of the five components of internal control and all relevant

principles are present and functioning
The five components are operating together in an integrated
manner
Principles are fundamental concepts associated with

components
Page 48
If a relevant principle is not present and functioning, the associated

component cannot be present and functioning
Controls will need to be mapped to the 17 principles and
deficiencies will need to be evaluated in the context of the 17
principles
COSO 2013
Transition
How long do issuers have to adopt the new framework?
Updated framework will supersede original framework at the end of

the transition period (i.e., 15 December 2014)
The SEC staff has indicated that the longer an issuer uses the
1992 framework after the transition period, the more likely it will be
that the SEC staff will have questions regarding the entitys internal
control assessment
Are there any additional disclosure requirements?
Page 49
During the transition period, entities reporting externally (and their

auditors) should disclose whether the original or updated version
of the framework was used
COSO 2013
Key points
2013 COSO framework requires that the company align

its internal control with the newly defined 17 principles
Although much of what we do today will not change

significantly, the 2013 COSO framework has additional
considerations we need to evaluate and document when
understanding the design of and testing internal controls
(transaction level and entity-level)
Page 50
Available resources
COSO
Internal Control Integrated Framework Executive Summary

Internal Control Integrated Framework and Appendices
Internal Control Integrated Framework Internal Control over
External Financial Reporting: A Compendium of Approaches
and Examples
Internal Control Integrated Framework Illustrative Tools for
Assessing Effectiveness of a System of Internal Control
EY
Publication: Transitioning to the 2013 COSO Framework for

External Financial Reporting Purposes (March 2014)
Page 51
Highlights key changes to the 2013 framework, a suggested project plan, questions
to consider when evaluating whether the 17 principles are addressed and an
example generic documentation template
COSO 2013

PCAOB Inspections Themes

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

PCAOB Inspections Themes

Enviado por

Direitos autorais:

Formatos disponíveis

PCAOB Inspection Themes

Update and COSO 2013

PCAOB Inspection Themes

Overview of PCAOB, inspection process, and recent

Recent IT-related PCAOB inspect

Better understanding flows of transactions, IT interfaces, and

Transition to COSO 2013

PCAOB Inspection Themes

Overview of PCAOB, inspection process, and

PCAOB Inspection Themes

IT-related PCAOB inspection themes

PCAOB Inspection Themes

Flows of transactions, IT interfaces, and

PCAOB Inspection Themes

PCAOB inspection theme

There have been instances in inspections in which teams

In these instances, some teams attempted to identify and

Common IT risks that need to be considered

Unauthorized initiation/authorization of transactions

Lack of segregation of incompatible duties

Reliance on IT applications or programs that are

Potential for errors and fraud within IT applications

Inappropriate dependence on the results of computer

Lack of transaction trails or loss of data

PCAOB Inspection Themes

System interface diagrams

System Interface flow charts provide the reader with a quick

assess the complexity of the IT environment

understand the inputs/outputs from systems

understand the types of electronic audit evidence generated

Understand applications and tools supporting significant process

PCAOB Inspection Themes

Example system interface diagram

PCAOB Inspection Themes

System interface inventory

Daily CDS transactions are balanced to

PCAOB Inspection Themes

Testing managements controls over

PCAOB Inspection Themes

PCAOB inspection theme

Not identifying and testing Issuer controls (either ITGC or business

Not testing completeness and accuracy of system generated data

Not testing IT general controls over all applications that produce

Not testing appropriate controls over end-user computing solutions

PCAOB Inspection Themes

Increased focus on issuer controls over EAE

Report changes need to be considered within change

Auditor needs to better consider controls that issuer has in

Auditor needs to better consider if system-generated data

PCAOB Inspection Themes

An example of audit documentation of EAE

Business process controls - Ctrl # INV # 3.1, 3.4, 3.7; P&P #

Changes to the PPV report are subject to the entitys ITGCs

Effective ITGCs over the Inventory application that maintains

Controls over the

Data and reports supporting the performance

PCAOB Inspection Themes

Data and reports supporting the performance

Step #1: What data or reports are used in the performance

PCAOB Inspection Themes

Data and reports supporting the performance

Step #2: Is the data or report generated by an in-scope

PCAOB Inspection Themes