Scope of this audit

This section states what was examined, what was not, how the work was done, and on what evidence the audit rests. It exists so that a sceptical reader — internal IT, an external partner, the system’s vendor, an acquiring company’s due-diligence team — can see exactly which claims in this document are evidence-based and which are inference.

2.1 What was examined

The audit covered:

• Production database (read-only) — schema inspection of all 280+ tables in the operational instance; row-count and growth-rate sampling; schema-vs-documentation reconciliation; query-plan inspection on 12 critical queries
• Application configuration — config files, parameter tables, scheduled-job definitions, custom report definitions, custom screen modifications
• Integration code (read-only) — the custom .NET integration broker source (where available — see §2.5 limitations); SSIS packages; scheduled batch scripts
• Operational history — incident log 2022–2026, change-management records 2020–2026, monthly close-cycle timing log
• User-facing artifacts — current user manual (last revised 2018), 8 internal SOP documents, training materials
• Live observation — 14 hours of role-walkthroughs across 7 user roles, 2 period-close cycles observed, 1 month-end close observed

2.2 What was not examined

The audit explicitly did not cover:

• Source code modification rights — we did not modify, recompile, or rebuild any part of the system
• Vendor contract and licensing — commercial terms, license-key dependencies, support-contract specifics are out of scope (these belong in a procurement / legal review, not a technical audit)
• Financial controls — internal-audit / SOX-style controls testing (segregation of duties, control effectiveness) is a separate discipline
• Statutory / regulatory compliance specifics — VAT, intrastat, accounting-standard alignment; we note where the system handles these but do not audit whether it handles them correctly per current regulation
• End-user productivity / UX research — user-friendliness, training effectiveness, opinion-shaped findings; we observe what users do, we do not survey what they feel
• Penetration testing — security observations are limited to configuration-level findings (default passwords, exposed shares, log retention); a formal pentest is a separate engagement
• Performance load-testing — we observe current-state performance and contention; we did not synthesise load to find break-points
• Vendor system internals — where the vendor’s compiled code is opaque (no source-access agreement), we treat it as a black box and document only its observable behaviour

2.3 Methodology

The audit followed a four-phase process over 14 working days on-site plus 6 working days off-site for analysis and write-up:

1. Phase 1 — Inventory (3 days on-site). Catalogue what exists. Database schema, config files, scheduled jobs, integrations, documentation, named users, named processes. Output: an inventory of every artifact the system comprises.
2. Phase 2 — Observation (5 days on-site). Watch the system in normal use. Role-walkthroughs with 7 named users covering 7 main user journeys (§5). Observe a period-close cycle. Observe normal-day operations. Output: narrative description of how the system actually behaves under load.
3. Phase 3 — Targeted inspection (6 days on-site + 4 days off-site). Drill into specific risk areas surfaced in Phase 2. Trace specific data flows end-to-end. Inspect integration broker behaviour. Inspect backup and recovery state. Output: evidence for the risk register (§11).
4. Phase 4 — Synthesis and write-up (2 days off-site). Assemble findings, structure the document, produce diagrams, draft modernisation options. Output: this document.

2.4 Evidence basis

Every claim in §3 through §11 is grounded in one or more of the following evidence types:

Evidence type	Symbol	Description
[OBS]	observed directly	Watched during walkthroughs, period-close, normal operations
[DOC]	documented evidence	Found in customer’s own documentation, SOPs, vendor manual
[DB]	database inspection	Verified by querying the production database
[CFG]	configuration evidence	Verified by inspecting config files, parameter tables
[INT]	interview	Stated by named user(s) during walkthrough or interview
[INF]	inference	Logical inference from other evidence; explicitly flagged where it appears

Tagged claims appear inline through the audit. A reader can audit our audit by checking that every claim carries appropriate evidence.

2.5 Limitations of this audit

Honest constraints we operated under:

• No source-access agreement with the system vendor. The vendor’s compiled binaries cannot be inspected; we documented their observable behaviour but cannot verify internal logic. This is the largest single methodological constraint and shapes which modernisation options in §12 are feasible.
• The 2014-era integration broker has partial source access (the company’s own code) but depends on third-party libraries whose source is not available. Some integration-broker behaviour is therefore documented as observed-only.
• Only one period-close cycle observed. Period-close is the highest-stakes operational moment; we observed one. Patterns described as “typical” are corroborated against the customer’s own close-cycle log but not personally observed across multiple cycles.
• No access to vendor support-ticket history. The vendor’s view of this customer’s incident pattern is not part of our evidence; we have only the customer-side ticket log.
• Documentation is partially stale. The 2018 user manual and the 8 SOPs document the system as of 2018; substantial undocumented configuration and customisation has accumulated since. Where documentation and observed reality diverge, we reflect observed reality and flag the divergence.
• Quantitative figures are approximate. Counts (“~120 production orders”) are based on representative-day samples, not exhaustive census. Where exact figures matter, a follow-up engagement would tighten these.

2.6 What “audit” means in this document

This document uses audit in its older, less compliance-laden sense: a thorough examination of an existing thing, conducted by an outside party, producing a written description of what is. It does not mean compliance audit, security audit, or financial audit — none of those is in scope.

The closest disciplinary parallel is a building condition survey: an experienced surveyor walks through, looks carefully at every part, knocks on a few walls, opens a few inspection panels, and writes down what they found. The output is descriptive, evidenced, and useful — but it does not change the building. Whether to renovate, repair, replace, or sell is a decision the owner makes, informed by the survey but not made by it.

That is the right mental model for this document.

2.7 Independence and disclosure

This audit was conducted by an outside party engaged under a paid audit-only contract, with no commercial commitment to subsequent work and no incentive structure tied to the size of any future engagement. The auditor’s interest in the customer’s outcome is professional reputation, not commission.

If, on completion of the audit, the customer commissions follow-on modernisation work, that is a separate engagement with separate scope and terms. Section §12’s modernisation considerations are written to be useful regardless of who delivers the work — they are options, not pitches.