Executive summary
Example Office can now search cloud sign-in, cloud administration, server security and office firewall records in one place. Tests confirmed that events from these four source types can be collected and retrieved. This gives investigators a clearer starting point and reduces the need to assemble those records from separate systems.
Coverage is incomplete. Application events have not been verified, and the two branch firewalls are not connected because licensing remains unresolved. These gaps could make it harder to establish who changed permissions or network settings, increasing investigation effort and uncertainty after an incident.
Recommended decisions
- Nominate the application contact and arrange a test that confirms relevant changes appear in the central records.
- Decide whether to fund branch firewall collection or formally accept the resulting investigation gap.
- Confirm who maintains collection, checks for missing events and verifies retention as history accumulates.
- Agree who investigates suspicious activity and how it is escalated.
Verified history begins on 1 September. The configured retention periods do not restore earlier records. This implementation supports investigation, but ongoing security monitoring and incident response have not been commissioned.
How to read the references
Reference codes connect the report's records so you can trace a conclusion back to its source. The numbers distinguish individual records; priority, confidence and completion status are stated separately.
- Log source L-01: A source of security records. L-01 is cloud sign-ins; L-02 cloud administration; L-03 server security; L-04 the office firewall; L-05 the business application; L-06 the branch firewalls.
- Validation test LT-01: A check of whether an event is collected and can be retrieved. The test table identifies the log source, action and result.
- Evidence L-E01: The retained record supporting a test or implementation check. Evidence references are explained in the handover section.
- Logging gap LG-01: An unresolved collection or verification issue. Each gap explains the business consequence and what is required to close it.
Colour key: Red act promptly · Orange needs attention; plan the fix · Green working, resolved or worth keeping. Each signal also carries its written label.
The report reference in the document details identifies the report as a whole. Client evidence references in these public examples are illustrative; no private evidence files are attached.
Source inventory and coverage
The business requested records useful for account misuse, administrative changes and investigation around a known time. Scope includes one cloud tenant, two office servers, one office firewall, one business application and two branch firewalls. Endpoint telemetry, message contents, network packet capture and other SaaS services are excluded.
| Log source / instances | Status | Events included | History / retention target |
|---|---|---|---|
| Log source L-01 · cloud sign-ins · 1 tenant | Validated | Available interactive sign-in records, account, result, source address | From 1 Sep · 180 days |
| Log source L-02 · cloud administration · 1 tenant | Validated | Supported audit events for role and configuration changes | From 1 Sep · 180 days |
| Log source L-03 · server security · 2 servers | Validated on both | Configured authentication and audit-policy events | From 1 Sep · 90 days |
| Log source L-04 · office firewall · 1 device | Validated | Administrative access and selected deny events | From 1 Sep · 90 days |
| Log source L-05 · business application · 1 instance | Configured, unverified | Intended administrator and permission changes | No verified history · target 90 days |
| Log source L-06 · branch firewall · 2 devices | Blocked at both branches | Intended administrative and selected network events | No central history · target 90 days |
“Validated” means the specific agreed event classes were observed, delivered, parsed and retrieved. It does not mean every event a product can produce is collected. The two cloud rows share a tenant but represent different feeds; coverage is stated by source type and instance so the total cannot be mistaken for a device count.
Data flow and access controls
Cloud feeds are read by separate collection connectors. The office servers and firewall forward the agreed records to a local collector, which sends them to the central search store. The application connector is present but has not passed its event test. The two branches have no implemented forwarding path.
The handover inventory identifies the collector, connector accounts, source identifiers, parser versions and destination datasets. Original event time and ingestion time are retained separately. Times are normalised to UTC for correlation and displayed here in AEST; the validation checked source-clock alignment for the tested events.
The example access model separates collection accounts, search-only investigators and configuration administrators. Administrator access uses individual accounts and multi-factor authentication. Collection secrets are held in the approved vault, with the provider responsible for expiry and rotation. The report contains vault references, not secret values.
Security logs may contain staff identifiers and network addresses. The business owner approves who may search them and for what purpose. Report exports use the controlled client evidence location, with unnecessary personal fields redacted before wider distribution. No email bodies or document contents were deliberately added to this baseline.
Validation and failure testing
Tests used agreed test accounts and reversible events. For each case, the provider recorded the source action, source timestamp, central event ID, parsed fields and retrieval query. Latencies below are individual test results, not a service-level commitment.
| Validation test / log source | Action and retrieval evidence | Observed result |
|---|---|---|
| Validation test LT-01 · Log source L-01 | Test-account sign-in at 10:00; event L-E01 retrieved by account and time | Pass · 84 seconds; actor, result and address present |
| Validation test LT-02 · Log source L-02 | Approved test-role assignment and reversal at 10:15; L-E02 | Pass · 112 seconds; actor and target present |
| LT-03a/b · Log source L-03 | Test sign-in on each server at 10:30 and 10:35; L-E03a/b | Pass · 18 / 23 seconds; both hosts identifiable |
| Validation test LT-04 · Log source L-04 | Test admin login and permitted test of a deny rule at 11:00; L-E04 | Pass · 9 / 12 seconds; correct source and action |
| Validation test LT-05 · Log source L-05 | Vendor could not arrange the test action | Not run · no acceptance evidence |
| LT-06a/b · Log source L-06 | No licensed export path at either branch | Blocked · no acceptance evidence |
Collection failure and recovery
LT-07 paused forwarding from the office collector at 11:30 on 4 September in an approved test window. The collection-health notification arrived at 11:42 and the provider acknowledged it at 11:47. Forwarding resumed at 11:50; the queued test event appeared centrally at 11:51. L-E07 contains the notification, acknowledgement and event record.
This proves the tested interruption was noticed and the queued event recovered. It does not establish that a long outage cannot exhaust local buffers. Source-specific stale-data checks were configured for L-01 to L-04, but independent cloud-feed failure simulations remain a follow-up acceptance item. L-05 and L-06 are not included in healthy-source totals.
Useful searches handed over
The provider demonstrated three saved searches: one account’s sign-ins over a specified interval; administrative changes by actor and target; and events for one server around a known timestamp. L-E08 records the search parameters and expected test event IDs. Product-specific query syntax belongs in the private runbook, tied to the actual dataset and field mappings.
Retention, capacity and cost assumptions
Sign-in and cloud audit datasets are configured for 180 days; server and firewall datasets for 90 days. Retention policy exports were checked, but a full 90- or 180-day lifecycle cannot have elapsed during this seven-day observation. Actual oldest-event availability and deletion behaviour must be rechecked as those milestones are reached.
The measured example ingest averages 0.6 GB/day for the two cloud feeds combined and 1.8 GB/day for servers and the office firewall. A simple steady-state planning calculation is (0.6 × 180) + (1.8 × 90) = 270 GB of raw event data. Search indexes, replicas, backups, compression and event growth are additional variables; 270 GB is not a provisioned-storage guarantee. Unimplemented sources are excluded.
| Item | Allowance | Assumption |
|---|---|---|
| Collection and searchable storage | $140/month | Current validated sources and measured volume only |
| Protected configuration backup | $20/month | Configuration recovery; not a second archive of every log |
| Provider maintenance | Separately scoped and priced | Health checks, access and capacity review; no incident monitoring |
| Branch licences / application charges | Not included · quotation required | Business approval needed before implementation |
The $160/month infrastructure allowance is a scenario budget, not a complete operating fee. Recalculate when representative operating volumes are available and after adding each source. Review projected capacity before 80% of the agreed allocation is reached. Investigations, unusually high event volumes and longer retention may require separate budget decisions.
What the remaining logging gaps mean
Logging gap LG-01 · Open acceptance item
Application changes may be missing from the investigation record
Observed: The application connector is configured, but no agreed test event has been verified. LT-05 was not run because the vendor could not arrange the action.
Why this matters: An attacker or unauthorised administrator could change permissions or settings without the central record showing who made the change and when. The event may exist at the source, but this has not been demonstrated.
If left unresolved: The team could trust an incomplete timeline, miss the scope of misuse and spend longer reversing unsafe changes. Configuration status alone is not evidence that an investigation question can be answered.
Action and closure: The application owner coordinates with the vendor to generate an approved reversible permission change. Confirm actor, target, outcome and timestamp centrally, retrieve the event and record latency. Close only when the evidence supports that result.
Logging gap LG-02 · Open acceptance item
Branch firewall activity is absent from central searches
Observed: Neither branch has an implemented licensed export path; LT-06a/b remain blocked.
Why this matters: An attacker with administrative access could alter branch firewall settings or an unauthorised device could generate relevant network events without those records appearing centrally. The absence of export does not itself give the attacker access.
If left unresolved: Investigators could overlook branch activity or need to recover short-lived local records separately. If those records expire first, the gap may become permanent, increasing uncertainty about containment and recovery.
Action and closure: The business owner decides whether to approve licensing and implementation for both sites. If approved, the provider validates each device independently. Otherwise record the affected questions, any verified alternative source, an accountable owner and a documented acceptance of the remaining gap.
Logging gap LG-03 · Open acceptance item
A failed cloud feed may create a silent gap
Observed: Source-staleness checks are configured, but independent failure simulations for the cloud feeds have not been completed. The tested collector outage covers a different path.
Why this matters: An expired connector credential, broken feed or other collection failure could stop account and administration events reaching the search store. Attacker activity during that interval could be missing from later searches, even if the original source recorded it.
If left unresolved: A quiet dashboard could be mistaken for a quiet environment. The loss might only be found during an incident, when source retention or expired access makes recovery difficult. This is an unverified failure-detection path, not a claim that the feeds have already failed.
Action and closure: The IT provider simulates each feed failure in an approved change window. Record who receives the health notification, acknowledgement and recovery. Verify whether events from the interruption are recovered or permanently absent.
Logging gap LG-04 · Open acceptance item
Configured retention does not yet prove usable history
Observed: The oldest verified records start on 1 September. The 90- and 180-day policy settings have not operated for a full retention cycle.
Why this matters: An intrusion or account misuse discovered later may need older records to establish first access and affected systems. Unexpected deletion, unrecognised gaps or insufficient storage could remove that evidence before the team asks for it.
If left unresolved: The business may assume it can look back months when it cannot. An investigation could then require broader precautionary checks and longer recovery decisions because the affected period cannot be reconstructed. Records from before collection started are already outside this baseline.
Action and closure: The IT provider verifies oldest searchable events, missing intervals, capacity and deletion behaviour as history accumulates. Check the complete retention lifecycle once it can actually be observed. Investigate any early loss, document the unavailable period and correct the cause.
Four follow-up items remain open. Acceptance of the four tested sources does not close these gaps. Vendor-dependent work is estimated after access and licensing are confirmed; changes in scope or ongoing response services need a separate agreement.
Operating runbook and responsibilities
Primary: the client’s IT provider service desk, during 08:30–17:00 AEST on business days. Backup: the client operations manager, who can escalate to the provider’s agreed support contact. These are fictional roles; a delivered runbook contains named contacts, tested routes and an approved service window. No after-hours response commitment is implied.
- On a collection-health notification: record the source, last good event and first known gap in a ticket. Check whether planned maintenance explains it and notify the backup if primary ownership is unavailable.
- Diagnose: inspect source activity, connector authentication, queue depth, network path and destination capacity. A quiet source is not automatically a broken collector; compare with expected activity or generate an approved test.
- Recover: correct the underlying issue through the change process, preserve diagnostic records, then verify a new event reaches the central store. Confirm whether buffered events were recovered or whether a permanent gap remains.
- Close and review: attach event IDs and timestamps, record the missing interval, and tell the business owner if the gap affects a current investigation. Do not erase evidence or extend retention globally without approval.
Ongoing operating tasks: Agree a maintenance schedule with the service owner. Check source freshness, connector errors and storage alarms; review capacity, permissions and expiring collection credentials; and verify sample retrieval queries and health-notification delivery. Repeat affected parser and event tests after upgrades and update contacts when responsibilities change. These tasks maintain collection; they do not constitute review of security activity.
Evidence and handover record
The example evidence index contains L-E01–L-E04 for validated source events, L-E07 for the failure drill, L-E08 for saved-search retrieval, L-E09 for retention and access exports, and L-E10 for the seven-day volume measurement. No originals are attached to this public example. A client evidence pack includes collection times, safe storage locations and exact test-event identifiers.
Delivered in this scenario: source inventory; collection diagram; configuration and recovery references; retention settings; access register; test record; saved searches; health runbook; and exception tracker. The provider demonstrates retrieval and recovery to the operations manager before handover.
Acceptance decision: four source types accepted for the tested events, two not accepted as operational, and four follow-up items remain open. The real acceptance record requires a named business approver, date and agreed residual gaps. Version 1.0 is the initial illustrative issue; no actual customer signature is represented.
The baseline cannot reconstruct records that were never collected, prove an incident did not occur or detect attacks by itself. Security alert rules and human triage would require separately agreed scope and ownership.