A SOC Report, or System and Organization Controls Report, is an independent assurance report on controls operated by a service organization. It helps customers and their auditors understand how the service provider processes information, protects systems and operates controls relevant to the outsourced service.
SOC Reports are commonly requested when a company outsources important activities such as cloud accounting, payroll processing, payment processing, data hosting, information technology operations, inventory systems or other transaction-processing functions. The report is prepared by an independent service auditor based on a description of the service organization’s system, specified control objectives or criteria, and tests performed on relevant controls.
A SOC Report is not a general certificate confirming that the service provider is completely secure or error-free. Its usefulness is limited to the services, systems, locations, controls and reporting period included within its scope. Management and the company’s auditor must therefore read the report carefully and relate it to the services actually used by the company.
Responsibility for financial reporting and internal control does not transfer to the service provider merely because a process has been outsourced. Management must still understand the outsourced process, monitor the provider and maintain controls over information sent to and received from the provider. Similarly, TSA 402 requires the user auditor to understand how the service organization affects the user entity’s internal control and to obtain sufficient appropriate audit evidence regarding the relevant transactions and controls.
The first step is to determine whether the correct type of SOC Report has been obtained. A SOC 1 report focuses on controls that may be relevant to customers’ internal control over financial reporting. It is normally the most relevant report where the service provider processes payroll, revenue, cash receipts, expenses, inventory or other information affecting the financial statements.
A SOC 2 report focuses on controls relating to security, availability, processing integrity, confidentiality and privacy. It can provide useful information about cybersecurity and system reliability, but it does not automatically replace a SOC 1 report when the audit objective concerns financial reporting. A provider may also issue other reports for more restricted or general-use purposes, so the intended users and purpose of the report should be understood.
The auditor must then distinguish between Type 1 and Type 2 reports. A Type 1 report considers the description and design of controls, including whether those controls were implemented, as of a specified date. It helps the auditor understand the system and assess whether the controls appear appropriately designed, but it does not provide evidence that they operated effectively throughout a period.
A Type 2 report covers both the design and operating effectiveness of controls over a stated period. It includes the service auditor’s testing procedures and results. Consequently, a Type 2 report is generally more useful when the user auditor intends to rely on the service organization’s controls to reduce substantive audit procedures.
The reporting period must also be appropriate. If a company closes its accounts on 31 December but the SOC 1 Type 2 report covers only the period to 30 September, the auditor must address the remaining three months. A bridge letter may state that no significant changes occurred after the end of the SOC period, but it is a representation from the service provider rather than an independent assurance opinion. It should be supported by other evidence, such as management inquiries, incident reports, change logs and service-review records.
The scope and system description should be read carefully. The auditor should confirm which legal entity, service, product, location, data centre, system version and process are included. A provider’s main platform may be covered while customer-specific configurations, implementation services, data migration, interfaces or local applications are excluded. The presence of the provider’s name on the report does not mean that every service used by the company is within scope.
The controls in the report should then be mapped to the company’s financial statement risks. Payroll controls, for example, may relate to the completeness and accuracy of payroll expenses and liabilities. Controls over payment processing may relate to cash receipts, refunds and settlement receivables. The purpose is not merely to confirm that controls exist, but to identify whether the controls address the relevant accounts and assertions being audited.
Particular attention should be given to Complementary User Entity Controls, or CUECs. These are controls that the service provider assumes the customer will perform. A payroll provider may assume that the company approves employee master-data changes, reviews payroll reports and reconciles payroll payments to the general ledger. A cloud provider may assume that the company approves user access, removes access when employees leave and reviews privileged accounts.
The service auditor’s conclusion normally assumes that these complementary controls operate at the customer. If the company has not implemented them, the SOC Report cannot compensate for that weakness. Each relevant CUEC should therefore be matched to the company’s actual control owner, frequency, procedure and supporting evidence. Where the auditor intends to rely on the control, its operating effectiveness must also be tested.
Subservice organizations must also be understood. The main provider may outsource part of its operations to another data centre, cloud provider, payment processor or software company. Under the inclusive method, relevant controls at the subservice organization are included in the report. Under the carve-out method, those controls are excluded. If a material outsourced function has been carved out, the auditor may need to obtain a separate SOC Report or perform alternative procedures.
The service auditor’s opinion should be read before reviewing the detailed testing results. The auditor should determine whether the opinion is unmodified or modified and understand the reason for any qualification or scope limitation. A modified opinion does not automatically make the entire report unusable, but its implications must be evaluated against the systems and risks relevant to the company.
The auditor should then review all relevant control exceptions. The number of exceptions alone is not sufficient. It is necessary to understand which control failed, how often the control should operate, the population and sample tested, the cause of the exception and whether corrective action was taken. One exception in a control performed daily may have a different implication from one exception in an annual control.
Exceptions should also be linked back to the company’s own transactions. If the report identifies failures in reviewing processing errors, the auditor should determine whether the company’s data was affected. If user access was not removed promptly, the auditor should assess whether unauthorised access to the company’s information may have occurred.
The nature and extent of the service auditor’s testing must be evaluated as well. A control may operate every day, but the service auditor may have tested only a limited number of occurrences. The user auditor should determine whether the testing performed provides sufficient evidence for the level of reliance planned.
A SOC Report rarely covers every control relevant to the company. Controls over data entered into the provider’s system, interfaces, review of reports, reconciliation to the general ledger, approval of system configurations and monitoring of service-level performance may remain the customer’s responsibility. The auditor must therefore understand the complete transaction flow from initiation to recording in the financial statements.
The reliability of information received from the provider must also be assessed. Even when the provider’s processing controls are effective, management may select an incomplete report, use incorrect parameters or modify data after extraction. The SOC Report does not automatically establish the completeness and accuracy of every report used by management or the auditor.
If the SOC Report is unavailable, covers the wrong period, excludes relevant systems or provides insufficient evidence, the auditor must perform alternative procedures. These may include obtaining additional information from the provider, visiting the service organization, requesting another auditor to test specific controls, reconciling outputs to external evidence or increasing substantive testing.
Management should not wait until year-end to request the report. Contracts with important service providers should require timely delivery of assurance reports, notification of significant incidents and cooperation with the company and its auditor. Finance, information technology, risk management and internal audit should review the report jointly and follow up on CUECs, exceptions and remediation plans.
In summary, a SOC Report is an independent assurance report on controls operated by a service organization. It is valuable audit evidence, but only within its defined scope and limitations. The auditor should confirm the correct report type, distinguish Type 1 from Type 2, assess the reporting period and scope, map controls to financial statement risks, test relevant CUECs, understand subservice organizations and investigate exceptions. Outsourcing changes where controls are performed, but it does not remove management’s responsibility for internal control or the auditor’s responsibility to obtain sufficient appropriate audit evidence.
SOC Report หรือรายงานเกี่ยวกับการควบคุมของระบบและองค์กร เป็นรายงานให้ความเชื่อมั่นที่จัดทำโดยผู้สอบบัญชีอิสระ เพื่อประเมินการควบคุมที่องค์กรผู้ให้บริการเป็นผู้ดำเนินการ รายงานนี้ช่วยให้บริษัทผู้ใช้บริการและผู้สอบบัญชีเข้าใจว่า ผู้ให้บริการประมวลผลข้อมูล ดูแลระบบ และปฏิบัติการควบคุมที่เกี่ยวข้องกับบริการที่รับจ้างอย่างไร
SOC Report มักถูกขอเมื่อบริษัทจ้างบุคคลภายนอกดำเนินงานสำคัญ เช่น ระบบบัญชีบนคลาวด์ การประมวลผลเงินเดือน การรับชำระเงิน การจัดเก็บข้อมูล การดูแลระบบเทคโนโลยีสารสนเทศ ระบบสินค้าคงเหลือ หรือระบบประมวลผลรายการอื่นที่มีผลต่อการดำเนินงานและงบการเงิน
อย่างไรก็ตาม SOC Report ไม่ใช่ใบรับรองทั่วไปว่าผู้ให้บริการมีความปลอดภัยสมบูรณ์หรือไม่มีข้อผิดพลาด รายงานให้ความเชื่อมั่นเฉพาะบริการ ระบบ สถานที่ การควบคุม และช่วงเวลาที่ระบุอยู่ในขอบเขตเท่านั้น ฝ่ายบริหารและผู้สอบบัญชีจึงต้องอ่านรายงานโดยเชื่อมโยงกับบริการที่บริษัทใช้จริง
การจ้างงานภายนอกไม่ได้ทำให้ความรับผิดชอบต่อการรายงานทางการเงินและการควบคุมภายในโอนไปยังผู้ให้บริการ ฝ่ายบริหารยังคงต้องเข้าใจกระบวนการที่จ้างภายนอก ติดตามผู้ให้บริการ และควบคุมข้อมูลที่ส่งให้กับผู้ให้บริการและข้อมูลที่ได้รับกลับมา มาตรฐานการสอบบัญชี รหัส 402 กำหนดให้ผู้สอบบัญชีทำความเข้าใจผลกระทบขององค์กรที่ให้บริการต่อระบบควบคุมภายในของกิจการ และต้องได้รับหลักฐานการสอบบัญชีที่เหมาะสมอย่างเพียงพอเกี่ยวกับรายการและการควบคุมที่เกี่ยวข้อง
เรื่องแรกที่ต้องพิจารณาคือ บริษัทได้รับ SOC Report ถูกประเภทหรือไม่ SOC 1 มุ่งเน้นการควบคุมที่เกี่ยวข้องกับการควบคุมภายในด้านการรายงานทางการเงินของบริษัทผู้ใช้บริการ จึงมักเป็นรายงานที่เกี่ยวข้องโดยตรงมากที่สุดเมื่อผู้ให้บริการประมวลผลเงินเดือน รายได้ เงินรับ ค่าใช้จ่าย สินค้าคงเหลือ หรือข้อมูลอื่นที่กระทบงบการเงิน
SOC 2 มุ่งเน้นการควบคุมด้านความมั่นคงปลอดภัย ความพร้อมใช้งาน ความถูกต้องของการประมวลผล การรักษาความลับ และความเป็นส่วนตัว รายงานประเภทนี้มีประโยชน์ต่อการประเมินความเสี่ยงด้านไซเบอร์และความน่าเชื่อถือของระบบ แต่ไม่สามารถใช้แทน SOC 1 เพื่อวัตถุประสงค์ของการตรวจสอบงบการเงินได้โดยอัตโนมัติ
จากนั้นต้องแยกระหว่าง Type 1 และ Type 2 รายงาน Type 1 ประเมินคำอธิบายระบบ การออกแบบการควบคุม และการนำการควบคุมไปใช้ ณ วันที่กำหนด รายงานประเภทนี้ช่วยให้ผู้สอบบัญชีเข้าใจระบบและพิจารณาว่าการควบคุมได้รับการออกแบบอย่างเหมาะสมหรือไม่ แต่ไม่ได้ให้หลักฐานว่าการควบคุมปฏิบัติงานอย่างมีประสิทธิผลตลอดช่วงเวลา
รายงาน Type 2 ครอบคลุมทั้งการออกแบบและประสิทธิผลของการปฏิบัติตามการควบคุมตลอดช่วงเวลาที่ระบุ พร้อมแสดงวิธีและผลการทดสอบของผู้สอบบัญชีขององค์กรที่ให้บริการ รายงาน Type 2 จึงมีประโยชน์มากกว่าเมื่อผู้สอบบัญชีต้องการพึ่งพาการควบคุมของผู้ให้บริการเพื่อลดขอบเขตการตรวจสอบเนื้อหาสาระ
ช่วงเวลาของรายงานต้องสอดคล้องกับรอบบัญชีของบริษัทอย่างเพียงพอ หากบริษัทปิดบัญชีวันที่ 31 ธันวาคม แต่รายงาน SOC 1 Type 2 ครอบคลุมเพียงถึงวันที่ 30 กันยายน จะมีช่วงเวลาสามเดือนที่ไม่อยู่ภายใต้รายงานให้ความเชื่อมั่น ผู้สอบบัญชีต้องประเมินว่าช่วงที่เหลือมีการเปลี่ยนระบบ เหตุการณ์ด้านความปลอดภัย หรือความล้มเหลวของการควบคุมหรือไม่
ผู้ให้บริการอาจออก Bridge Letter เพื่อยืนยันว่าไม่มีการเปลี่ยนแปลงที่สำคัญหลังสิ้นสุดช่วงของ SOC Report แต่หนังสือดังกล่าวเป็นคำรับรองของผู้ให้บริการ ไม่ใช่รายงานจากผู้สอบบัญชีอิสระ จึงควรใช้ร่วมกับหลักฐานอื่น เช่น การสอบถามฝ่ายบริหาร รายงานเหตุการณ์ บันทึกการเปลี่ยนแปลงระบบ และรายงานการติดตามบริการ
ผู้สอบบัญชีต้องอ่านขอบเขตและคำอธิบายระบบอย่างละเอียด โดยตรวจว่ารายงานครอบคลุมนิติบุคคล บริการ ผลิตภัณฑ์ ศูนย์ข้อมูล รุ่นของระบบ สถานที่ และกระบวนการที่บริษัทใช้จริงหรือไม่ ผู้ให้บริการอาจมีรายงานครอบคลุมระบบหลัก แต่ไม่รวมการติดตั้ง การตั้งค่าระบบเฉพาะลูกค้า การย้ายข้อมูล การเชื่อมต่อระหว่างระบบ หรือโปรแกรมที่ใช้เฉพาะในแต่ละประเทศ
การที่ชื่อผู้ให้บริการปรากฏบน SOC Report จึงไม่ได้หมายความว่าบริการทั้งหมดที่บริษัทใช้จะอยู่ในขอบเขตของรายงาน
จากนั้นควรเชื่อมการควบคุมในรายงานเข้ากับความเสี่ยงของงบการเงิน ตัวอย่างเช่น การควบคุมระบบเงินเดือนอาจเกี่ยวข้องกับความครบถ้วนและความถูกต้องของค่าใช้จ่ายกับหนี้สินพนักงาน ส่วนการควบคุมระบบรับชำระเงินอาจเกี่ยวข้องกับเงินรับ รายการคืนเงิน และลูกหนี้จากผู้ให้บริการชำระเงิน การอ่านรายงานโดยไม่เชื่อมกับบัญชีและความเสี่ยงที่กำลังตรวจสอบ อาจทำให้มีเอกสารประกอบจำนวนมาก แต่ไม่ได้ให้หลักฐานที่ตรงกับวัตถุประสงค์ของงาน
ส่วนที่สำคัญมากคือ Complementary User Entity Controls หรือ CUECs ซึ่งหมายถึงการควบคุมที่ผู้ให้บริการสมมติว่าบริษัทผู้ใช้บริการต้องดำเนินการเอง ตัวอย่างเช่น ผู้ให้บริการเงินเดือนอาจกำหนดว่าบริษัทต้องอนุมัติการเปลี่ยนข้อมูลพนักงาน สอบทานรายงานเงินเดือน และกระทบยอดยอดจ่ายกับบัญชีแยกประเภท ส่วนผู้ให้บริการคลาวด์อาจกำหนดให้บริษัทอนุมัติสิทธิผู้ใช้งาน ยกเลิกสิทธิเมื่อพนักงานลาออก และสอบทานผู้ใช้งานที่มีสิทธิระดับสูง
ข้อสรุปใน SOC Report มักตั้งอยู่บนสมมติฐานว่าการควบคุมเหล่านี้ได้รับการปฏิบัติที่บริษัทผู้ใช้บริการ หากบริษัทไม่ได้ดำเนินการ SOC Report ไม่สามารถทดแทนช่องว่างดังกล่าวได้ ผู้สอบบัญชีควรจับคู่ CUEC แต่ละข้อกับกระบวนการ ผู้รับผิดชอบ ความถี่ และหลักฐานการปฏิบัติงานของบริษัท และหากต้องการพึ่งพาการควบคุม ต้องทดสอบด้วยว่าการควบคุมปฏิบัติงานอย่างมีประสิทธิผลหรือไม่
อีกเรื่องหนึ่งคือ Subservice Organization หรือผู้ให้บริการช่วง ผู้ให้บริการหลักอาจว่าจ้างศูนย์ข้อมูล ผู้ให้บริการคลาวด์ ผู้ประมวลผลการชำระเงิน หรือบริษัทซอฟต์แวร์อื่นดำเนินงานบางส่วน หากรายงานใช้วิธี Inclusive การควบคุมของผู้ให้บริการช่วงจะรวมอยู่ในรายงาน แต่หากใช้วิธี Carve-out การควบคุมของผู้ให้บริการช่วงจะถูกตัดออกจากขอบเขต
หากกระบวนการสำคัญถูกตัดออก ผู้สอบบัญชีอาจต้องขอ SOC Report แยกของผู้ให้บริการช่วง หรือดำเนินวิธีตรวจสอบอื่นเพื่อให้ได้หลักฐานที่เพียงพอ
ผู้สอบบัญชีควรอ่านความเห็นของผู้สอบบัญชีขององค์กรที่ให้บริการก่อนอ่านผลการทดสอบรายละเอียด โดยพิจารณาว่าเป็นความเห็นแบบไม่มีเงื่อนไขหรือมีการเปลี่ยนแปลงความเห็น และสาเหตุของการเปลี่ยนแปลงเกี่ยวข้องกับระบบที่บริษัทใช้หรือไม่ รายงานที่มีข้อยกเว้นไม่ได้หมายความว่าใช้ไม่ได้ทั้งหมด แต่ต้องประเมินผลกระทบต่อความเสี่ยงและระดับการพึ่งพาการควบคุม
ข้อยกเว้นในการทดสอบแต่ละรายการต้องได้รับการอ่านอย่างละเอียด จำนวนข้อยกเว้นเพียงอย่างเดียวไม่เพียงพอ ผู้สอบบัญชีต้องเข้าใจว่าการควบคุมใดล้มเหลว ต้องปฏิบัติบ่อยเพียงใด ประชากรและตัวอย่างที่ทดสอบมีขนาดเท่าใด สาเหตุคืออะไร และผู้ให้บริการแก้ไขแล้วหรือไม่ ข้อยกเว้นหนึ่งรายการในการควบคุมประจำวันอาจมีความหมายต่างจากข้อยกเว้นหนึ่งรายการในการควบคุมที่ทำปีละครั้ง
นอกจากนี้ ต้องเชื่อมข้อยกเว้นกลับมายังข้อมูลของบริษัท หากมีความล้มเหลวในการสอบทานข้อผิดพลาดจากการประมวลผล ผู้สอบบัญชีควรตรวจว่าข้อมูลของบริษัทได้รับผลกระทบหรือไม่ หากมีการยกเลิกสิทธิผู้ใช้งานล่าช้า ต้องประเมินว่าบุคคลดังกล่าวสามารถเข้าถึงข้อมูลของบริษัทได้หรือไม่
ลักษณะและขอบเขตการทดสอบของผู้สอบบัญชีขององค์กรที่ให้บริการก็มีความสำคัญ แม้การควบคุมจะดำเนินการทุกวัน แต่อาจมีการเลือกทดสอบเพียงบางรายการ ผู้สอบบัญชีของบริษัทจึงต้องพิจารณาว่าการทดสอบดังกล่าวเพียงพอต่อระดับการพึ่งพาที่วางแผนไว้หรือไม่
SOC Report โดยทั่วไปไม่ได้ครอบคลุมการควบคุมทั้งหมดของบริษัท การควบคุมข้อมูลที่ส่งเข้าสู่ระบบ การเชื่อมต่อระหว่างระบบ การสอบทานรายงาน การกระทบยอดกับบัญชีแยกประเภท การอนุมัติการตั้งค่าระบบ และการติดตามผลการให้บริการอาจยังเป็นความรับผิดชอบของบริษัท ผู้สอบบัญชีจึงต้องทำความเข้าใจกระบวนการทั้งหมดตั้งแต่เริ่มรายการจนบันทึกในงบการเงิน ไม่ใช่เฉพาะส่วนที่ผู้ให้บริการดำเนินการ
ความน่าเชื่อถือของข้อมูลที่ได้รับจากผู้ให้บริการต้องประเมินแยกต่างหากด้วย แม้ระบบของผู้ให้บริการจะมีการควบคุมที่ดี แต่ฝ่ายบริหารอาจดึงรายงานไม่ครบ กำหนดเงื่อนไขผิด หรือแก้ไขข้อมูลภายหลังการดึงออกมา SOC Report จึงไม่ได้ยืนยันโดยอัตโนมัติว่ารายงานทุกฉบับที่บริษัทหรือผู้สอบบัญชีใช้นั้นครบถ้วนและถูกต้อง
หากไม่มี SOC Report รายงานครอบคลุมช่วงเวลาไม่เพียงพอ ตัดระบบสำคัญออก หรือไม่สามารถให้หลักฐานตามวัตถุประสงค์ของงาน ผู้สอบบัญชีต้องใช้วิธีตรวจสอบอื่น เช่น ขอข้อมูลเพิ่มเติมจากผู้ให้บริการ เข้าไปตรวจ ณ สถานที่ของผู้ให้บริการ มอบหมายให้ผู้สอบบัญชีอื่นทดสอบการควบคุม กระทบยอดข้อมูลกับหลักฐานภายนอก หรือเพิ่มการตรวจสอบเนื้อหาสาระ
ฝ่ายบริหารไม่ควรรอจนใกล้สิ้นปีจึงขอ SOC Report สัญญากับผู้ให้บริการสำคัญควรกำหนดให้ส่งรายงานอย่างทันเวลา แจ้งเหตุการณ์สำคัญ และให้ความร่วมมือกับบริษัทและผู้สอบบัญชี ฝ่ายการเงิน ฝ่ายเทคโนโลยีสารสนเทศ ฝ่ายบริหารความเสี่ยง และฝ่ายตรวจสอบภายในควรอ่านรายงานร่วมกัน รวมทั้งติดตาม CUECs ข้อยกเว้น และการแก้ไขข้อบกพร่องอย่างเป็นระบบ
โดยสรุป SOC Report คือรายงานให้ความเชื่อมั่นอย่างเป็นอิสระต่อการควบคุมขององค์กรที่ให้บริการ และเป็นหลักฐานที่มีประโยชน์ทั้งต่อฝ่ายบริหารและผู้สอบบัญชี อย่างไรก็ตาม รายงานมีขอบเขตและข้อจำกัดที่ต้องทำความเข้าใจ ผู้สอบบัญชีควรตรวจว่ารายงานถูกประเภท แยก Type 1 กับ Type 2 ประเมินช่วงเวลาและขอบเขต เชื่อมการควบคุมกับความเสี่ยงของงบการเงิน ทดสอบ CUECs ทำความเข้าใจผู้ให้บริการช่วง และติดตามข้อยกเว้นอย่างละเอียด การจ้างงานภายนอกเปลี่ยนสถานที่ที่มีการปฏิบัติการควบคุม แต่ไม่ได้ลดความรับผิดชอบของฝ่ายบริหารต่อการควบคุมภายใน หรือความรับผิดชอบของผู้สอบบัญชีในการได้รับหลักฐานการสอบบัญชีที่เหมาะสมอย่างเพียงพอ
