Audit Request and Submission
The audit request and submission is Step 2 of the TQS certification process, where the project team applies for a formal audit after completing the pre-review. This chapter defines the required deliverables, deliverable preparation guide, submission procedures, audit costs, and schedule coordination.
31.3.1. Required Deliverables
The project team must submit the following deliverables when requesting an audit. Deliverables are classified as mandatory and recommended, and submissions with missing mandatory deliverables will be rejected.
| No. | Deliverable | Description | Mandatory |
|---|---|---|---|
| 1 | Self-Assessment Checklist | Compliance status and supporting evidence per item (including screenshots/links) | Mandatory |
| 2 | Project Repository Access | Read access to source code (GitHub) | Mandatory |
| 3 | CI/CD Pipeline Results | Last 5 build/test pass records (CircleCI) | Mandatory |
| 4 | Test Coverage Report | JaCoCo (backend) + Vitest coverage (frontend) | Mandatory |
| 5 | Dependency Security Scan Report | OWASP Dependency-Check results | Recommended |
| 6 | Lighthouse Report | Performance/accessibility scores (for projects with frontend) | Recommended |
| 7 | Project Architecture Document | System architecture diagram, technology stack description, key design decisions | Recommended |
Mandatory deliverables are the minimum materials required for the TQS Committee to conduct an audit. Recommended deliverables are supplementary materials that improve audit efficiency and enhance the auditor's understanding of the project. An audit will proceed even if recommended deliverables are not submitted, but the audit of those areas may require more time.
Projects targeting Advanced or Premier grades are encouraged to submit all recommended deliverables. This is because they serve as supporting evidence for proving compliance with recommended items.
31.3.2. Deliverable Preparation Guide
This section provides specific preparation methods and formats for each deliverable. Deliverables must be prepared in the prescribed format, and submissions that do not conform to the format may receive a remediation request.
31.3.2.1. Self-Assessment Checklist
The self-assessment checklist is a document recording the compliance status for all items in the TQS Certification Checklist (Chapter 32).
| Field | Preparation Method |
|---|---|
| Item Number | Use the original item number from the checklist |
| Compliance Status | Mark as Compliant (O), Partially Compliant (△), Non-Compliant (X) |
| Supporting Evidence | If compliant: configuration file path, screenshot, CI log link |
| If partially compliant: specify current value and target value | |
| If non-compliant: state the reason for non-compliance | |
| Remarks | Additional explanation or special notes for the item |
The self-assessment checklist serves as the starting point for the audit. It must be prepared accurately and honestly; discrepancies between the documented and actual state may raise credibility issues during the audit process.
31.3.2.2. Project Repository Access
Read access to the GitHub repository must be granted so the TQS Committee can directly review the source code.
- For private repositories, grant Collaborator (Read) access to the TQS Committee's GitHub organization account or individual auditor accounts.
- For repositories belonging to an organization, add the TQS Committee account to the appropriate team within the organization.
- Access must be maintained during the audit period and may be revoked after audit completion.
- The default branch (main or master) of the repository must reflect the latest state of the version under audit.
31.3.2.3. CI/CD Pipeline Results
CI/CD pipeline results are materials that demonstrate the project's builds, tests, and lint verifications are continuously passing.
| Submission Item | Detailed Requirements |
|---|---|
| Last 5 build records | CircleCI dashboard screenshots or build URLs |
| Step-by-step results for each build | Success/failure status for each lint, test, and build step |
| Failure history inclusion | If any of the last 5 builds contain failures, include failure reasons and resolution details |
| Pipeline configuration file | .circleci/config.yml file path must be accessible |
All of the last 5 builds must be in a success state. If failures are included among the 5 builds, the cause and resolution process for each failure must be specified. Repeated build failure history may be viewed as a negative factor during the audit.
31.3.2.4. Test Coverage Report
The test coverage report is material that quantitatively demonstrates the sufficiency of project testing.
Backend (JaCoCo):
- Submit the HTML report generated after running
mvn test jacoco:report. - Report path:
target/site/jacoco/index.html - Line coverage of 80% or above and branch coverage of 70% or above must be achieved.
- Both project-level coverage and package-level coverage must be verifiable.
Frontend (Vitest):
- Submit the coverage report generated after running
npx vitest run --coverage. - Line coverage of 80% or above and branch coverage of 70% or above must be achieved.
- Coverage for component tests, composable tests, and store tests must all be included.
31.3.2.5. Dependency Security Scan Report
Submit the security scan report generated by running OWASP Dependency-Check. This deliverable is recommended, but must be submitted if targeting Advanced or Premier grades.
- Submit the HTML report generated after running
mvn dependency-check:check. - There must be no vulnerabilities with a CVSS (Common Vulnerability Scoring System) score of 7 or above.
- If vulnerabilities exist, a response plan (e.g., version upgrade schedule) must be submitted together.
31.3.2.6. Lighthouse Report
Projects that include a frontend are encouraged to submit a Lighthouse report.
- Generate the report using the Lighthouse tab in Chrome DevTools or the Lighthouse CLI.
- Submit reports for each key page (login, dashboard, main feature pages).
- A performance score of 90 or above must be achieved.
- Accessibility, Best Practices, and SEO scores should also be included as reference material.
31.3.2.7. Project Architecture Document
This document describes the overall technical structure of the project. It helps auditors quickly understand the project.
- System architecture diagram (backend, frontend, database, external integration configuration)
- Technology stack list and selection rationale
- Key design patterns and architectural decisions
- Directory structure description
31.3.3. Submission Procedures
The audit request submission procedure proceeds in the following 4 steps.
31.3.3.1. Procedure Flow
The details of each step are as follows.
| Step | Responsible Party | Activity | Duration |
|---|---|---|---|
| Submission | Project Team | Submit all deliverables to the TQS Committee | --- |
| Document Verification | TQS Committee | Verify inclusion of mandatory deliverables and format compliance | 1 business day |
| Receipt Notification | TQS Committee | Notify of receipt completion or remediation request | 1 business day |
| Audit Schedule Confirmation | TQS Committee | Notify of audit start date and auditor assignment | 2 business days |
31.3.3.2. Document Verification Criteria
The TQS Committee verifies the following for submitted deliverables.
- Verifies that all 4 mandatory deliverables are included.
- Verifies that the format of each deliverable conforms to the criteria defined in this chapter.
- Verifies that access to the project repository has been properly granted.
- Verifies that the self-assessment checklist includes all items.
If deficiencies are found during document verification, the TQS Committee notifies the project team of a remediation request. The remediation request includes the specific details of the deficiency and a remediation deadline. The remediation deadline is within 3 business days from the notification date.
31.3.3.3. Submission Rejection Reasons
Audit requests are rejected in the following cases.
- Mandatory deliverables are missing
- The self-assessment checklist clearly indicates non-compliance of mandatory items (5 or more non-compliant mandatory items)
- Project repository access is unavailable
- Remediation was not completed within the deadline following a remediation request
If a submission is rejected, the project team may re-request an audit after resolving the rejection reasons. There is no limit on the number of re-requests.
31.3.4. Audit Costs
TQS certification is an internal certification system of TIENIPIA. Therefore, no separate audit costs are incurred.
The TQS Committee's audit activities are handled as part of the committee's responsibilities. The project team bears no costs when requesting an audit, and no additional costs are incurred based on audit results.
However, development resources required for remediation work are borne by the project team. It is efficient to minimize remediation work through thorough preparation during the pre-review stage.
If external consultation is needed, the associated costs are funded from the TQS Committee's operational budget. No separate costs are charged to the project team.
31.3.5. Schedule Coordination
The audit schedule is confirmed through consultation between the TQS Committee and the project team. Coordination must be done in advance to prevent conflicts between the project's release schedule and the audit schedule.
31.3.5.1. Audit Start Deadline
The audit must commence within 5 business days from the date of submission receipt. The TQS Committee notifies the expected audit start date at the time of receipt notification.
If starting the audit within 5 business days is not possible (due to committee schedule, excessive concurrent audits, etc.), the TQS Committee must notify the project team of the delay reason and the revised expected audit start date.
31.3.5.2. Release Schedule Considerations
It is recommended that project teams submit their next release schedule when requesting an audit. The TQS Committee conducts the audit considering the project's release schedule.
- If the release date is imminent, a priority audit may be requested.
- Acceptance of priority audits is determined at the discretion of the TQS Committee.
- Even if a priority audit is accepted, audit criteria are applied identically.
31.3.5.3. Audit Schedule Changes
If a change to the audit schedule is needed after submission confirmation, the change must be requested at least 2 business days before the scheduled audit start date. Schedule changes after the audit start date are, in principle, not permitted.
If the audit is interrupted due to the project team's circumstances during the audit, the audit is treated as cancelled, and a new audit request must be submitted to proceed again in the future.