Blog Posts

Cyber Incident First Hour: A Communications Decision Guide

Communications and technical specialists managing the first hour of a digital service outage in Istanbul
Uğur Alkapar
Uğur Alkapar

Cyber Incident First Hour: A Communications Decision Guide

What must communications achieve in the first hour?

Communications must establish a reliable rhythm before the technical team has a complete diagnosis. The first public update should state the verified service impact, give people a safe action, explain that investigation is under way and name the time of the next update.

A failed login, unavailable payment page or disconnected customer portal is evidence of disruption, not evidence of a cyberattack. The underlying cause might be malicious activity, a supplier failure, a flawed software release, excessive demand or a physical network fault. Calling the event an attack too early can create unnecessary fear and prejudice an investigation; calling it routine maintenance without proof can destroy trust later.

The problem is amplified when a company serves several markets. A consumer in Türkiye may see a social post before a status page, while a UK enterprise customer expects an account manager to confirm contractual continuity. An EU partner may ask whether a formal incident threshold has been reached. One source of truth should feed those channels, but each audience needs a useful version rather than a literal translation.

Google Trends data for Türkiye offers a timely search signal. “İnternet kesintisi”, meaning internet outage, produced a sharp relative-interest peak during the last 30 days, while “siber saldırı mı var”, meaning is there a cyberattack, appeared among the rising related queries over 12 months. These figures are not search volumes. They show how quickly people join visible impact and suspected cause in the same question.

When can an outage be called a cyberattack?

An outage can be called a cyberattack only when authorised incident leadership has enough technical evidence to support that conclusion. Until then, the organisation should describe the observed disruption and keep cause, data impact and attribution in the investigation column.

That standard applies equally to reassuring language. “No personal data was affected” is a definitive claim, not a neutral holding line. If analysts have not completed the relevant checks, a more accurate statement is that the organisation is investigating whether unauthorised access occurred and will update affected people when evidence is available.

The UK National Cyber Security Centre advises organisations to avoid premature conclusions about cause, scale or the actor behind an incident. Its guidance on effective cyber incident communications also warns against assurances that may need to be withdrawn and recommends clear, accessible and timely updates for staff, customers, stakeholders and media.

A four-column incident brief keeps the language disciplined:

  • Verified: the affected services, user groups, markets and start time that teams can support with evidence.
  • Under investigation: root cause, unauthorised access, supplier dependencies and the likely recovery path.
  • Actions in progress: containment, continuity and customer-support measures that can be described safely.
  • Restricted: details that could expose security controls, personal information or investigative evidence.

The incident commander, security lead, legal adviser, customer operations lead and spokesperson should work from the same brief. An integrated PR and evidence workflow is useful here because inconsistency often begins inside the organisation before it becomes a public contradiction.

What should the first public statement contain?

The first public statement should contain five elements: the problem observed, the verified user impact, a safe customer action, the response now under way and the time of the next update. It should state plainly when the cause is not yet known.

A practical holding statement might say: “Some customers cannot currently access account and payment services. Our technical and security teams are working to limit the impact and determine the cause. Please do not use password-reset links received outside our official channels. We will publish another update at 14:30 local time.” The exact action must fit the incident; a generic security instruction can confuse people if it is not relevant.

The update does not need to promise that everything is under control. It does need to show that the organisation knows which questions remain open and has set a credible return time. Silence leaves customers, staff and journalists to construct a cause from incomplete screenshots and anonymous claims.

Use a short pre-publication check:

  • Has every statement about an unaffected service been tested?
  • Could the technical detail help an attacker or compromise evidence?
  • Does the customer action lead to a working, verified channel?
  • Is the wording accessible to people without security expertise?
  • Can the response team meet the promised update time?

Prepare a separate media question sheet from the same facts. Likely questions include whether the incident is ransomware, when services will return, whether personal data was accessed and which authorities have been notified. Each answer should distinguish what is verified, what is being tested and what cannot yet be disclosed. This is also why international media work needs more than one distributed statement: journalists require live access to a prepared spokesperson and updated evidence.

How should the 60-minute workflow be divided?

The first hour should be divided into three decision windows: 0–15 minutes, 15–30 minutes and 30–60 minutes. A public post is not required at the end of every window, but the internal evidence record and approval state must be refreshed.

Minutes 0–15: appoint the incident commander, technical contact, legal owner and single authorised spokesperson. Check whether corporate email, the main website and normal collaboration tools are available. If they are not, move to the previously verified continuity channel rather than improvising access during the incident.

Minutes 15–30: confirm the affected service and the action that users should take or avoid. Draft the first statement on the shared incident brief. Security, operations and legal owners should approve the same compact version, with unresolved cause and data questions clearly marked.

Two communications specialists preparing the first public update during a digital service outage
A first-hour record keeps technical findings and publishable facts connected without treating them as the same information.

Minutes 30–60: publish the core facts through the status page, official social account, customer-support script and media contact as appropriate. The formats may differ, but the impact, safe action and next-update time must match. Start a separate log for misinformation, impersonation accounts and false support links.

Evidence: FL PR & Communications presents fast, proactive media responses during a crisis as a process tied to preparation and reputation management. Its official Instagram post of 16 August 2026 frames a Global Communications Check-Up as three short steps with a timed written result. These are first-party operating signals, not earned-media outcomes; they informed this article’s compact intake, named deadline and written record.

The agency’s public corporate PR material also places media readiness, news-cycle monitoring and crisis planning in one workflow. That supports an active communications desk which updates verified facts while technical response continues, rather than waiting for a finished forensic report before acknowledging visible disruption.

How do regulatory notices differ from customer updates?

Regulatory notices and customer updates serve different recipients, thresholds and evidence needs, so completing one does not automatically complete the other. The legal track records reportable facts; the public track helps affected people make safe decisions.

In Türkiye, if personal data is confirmed to have been obtained by unlawful means, the data controller must notify the Personal Data Protection Authority without delay and no later than 72 hours after becoming aware. The Authority’s current public notice on breach notification also explains that affected people should be notified by an appropriate method within the shortest reasonable time once they are identified.

The 72-hour limit is not a reason to wait three days before acknowledging an outage. During the first hour, the organisation can state the operational impact, the continuing investigation and the action customers should take without claiming that a personal data breach has or has not occurred. If a breach is later confirmed, legal and security teams should align the formal notice, evidence record and affected-person communication without copying one document into every channel.

For essential and important entities within scope in the European Union, NIS2 uses a staged reporting sequence for significant incidents. Article 23 of the NIS2 Directive provides, where applicable, for an early warning within 24 hours, an incident notification within 72 hours and a later final report. It also addresses prompt communication of measures that service recipients can take to reduce risk.

A Turkish company serving EU customers is not automatically in scope. Entity type, sector, establishment, local implementation and the service supplied all require qualified legal assessment. Communications teams should nevertheless understand the operating lesson: a concise early warning can be useful before root cause is final, provided its uncertainty and evidence limits are explicit.

Technical indicators supplied to a regulator or incident-response body should not be pasted into a public post. A customer needs to know the service effect, personal risk, protective action, support route and update time. The authority may need severity, indicators, cross-border effect and mitigation records.

How should communication continue after the first hour?

After the first hour, communication should follow verified changes rather than a stream of repetitive reassurance. Each update needs a timestamp, an owner, a meaningful change and a clear instruction or next-update commitment.

During the first day, log the exact publication time, approver and change in every statement. Classify the first 20 customer questions. Track service-restoration questions separately from suspected data loss, impersonation, false causation and regional availability. The European Union Agency for Cybersecurity also recommends preserving evidence, contacting the appropriate authority and informing affected parties; its cyber incident awareness guidance treats reporting and help-seeking as part of limiting harm.

The company should maintain alternative routes because the incident may disable its usual channels. A tested status domain, independent phone line and verified social account are more reliable than a continuity plan stored only inside the affected network. Staff also need an internal route that does not depend on corporate email.

Market differences should be recorded rather than handled by ad hoc translation. A Turkish consumer may need a concise operational update; a UK enterprise customer may ask about continuity commitments; an EU partner may need to map the event to local reporting duties. A verifiable authority model for public communication depends on keeping the organisation, spokesperson, claim and supporting source consistent across those markets.

Close the communications incident only after the service status, customer guidance and public record agree. The review should answer three measurable questions: how many minutes passed before the first verified update, how many claims later required correction and how many users were sent to an unavailable or unofficial channel. Those results become the objectives of the next tabletop exercise.

Trust is not demonstrated by appearing certain before evidence exists. It is demonstrated by separating effect from cause, meeting promised update times and correcting the record visibly when facts change. connecting PR content with durable public evidence also helps the accurate incident record remain easier to find than rumours after the immediate disruption has ended.

Frequently Asked Questions

These answers cover the most common first-hour decisions about cause, data, channels and formal notification.

Must a company know the root cause before its first update?

No. It can explain the verified service impact, investigation in progress, safe customer action and next update time before root cause is known, provided it does not present a suspected cause as fact.

Can the first statement say that no data was compromised?

Only when the relevant technical investigation supports that conclusion. If assessment is continuing, the statement should describe what is known so far and commit to notifying affected people if evidence changes.

Where should updates appear if the corporate website is down?

Use a previously verified independent status page, official social account, customer phone line or continuity channel. The route should be tested before an incident and clearly distinguished from impersonation accounts.

Does notifying a regulator replace customer communication?

No. A regulator receives the formal record required by law, while customers need clear information about service impact, personal risk, protective action, support and the next expected update.