Before testing beginswhat should your team prepare?

1 - Prerequisites

Before testing begins, written authorization, proof of ownership, and an asset inventory must be completed. The technical phase does not proceed until these three items are in place.

• Written authorization: scope, validity period, and stop conditions are defined together.
• Ownership verification: a document proving your authority over the asset under test is provided.
• Asset inventory: which web, API, and mobile components are in scope and which are excluded is established.
• Critical flow list: flows involving authorization boundaries, tenant separation, or business logic take priority.

2 - Providing access

A separate access set is prepared for each of the web, API, and mobile components. When a document or account is missing, the test drops from gray-box to black-box level and the depth of findings decreases.

• For web: a URL inventory and role-based test accounts (admin, standard user, restricted) are provided.
• For API: the base URL, an OpenAPI, Swagger, or Postman collection, and test keys are supplied.
• For mobile: the APK and IPA binaries along with the relevant API access details are provided.
• An architecture diagram or system flow summary; a single page is sufficient.
• If IP allowlisting is required, the testing source IP range is clarified in advance.

3 - Stakeholder list

Throughout the test window, three stakeholder lines must remain open: technical, product, and security. A primary and backup contact for each line is recorded in writing.

• Technical contact: the decision-maker on the engineering side (CTO or Engineering Lead).
• Product contact: the product owner who knows the critical flows and business logic.
• Security contact: the information security lead or application security officer.
• Backup contact: an alternate reachable with a single call when the primary is unavailable.

4 - Deliverable preferences

Report language, compliance mapping, and additional deliverable decisions are fixed together with the scope. A late deliverable request shifts the schedule.

• Report language: Turkish or English; a dual language is a separate cost item.
• Compliance mapping: ISO 27001, SOC 2, and PCI DSS are optional.
• Executive summary distribution list: the decision readers management will want to see are identified.
• Retest preference: planned as part of the close-and-verify cycle.

5 - Schedule and test window

The test schedule is clarified through questions of whether the release is frozen, whether execution is during or outside business hours, and whether parallel work is present. Expedited delivery adds a premium.

• Release freeze: a frozen release is preferred during the test window.
• In-hours or after-hours preference: the on-call line and communication channel are set accordingly.
• Parallel work: results are cleaner when no other test or migration runs in the same environment.
• Expedited delivery: a 15 percent premium applies under 10 business days, and 30 percent under 5 business days.

1 - Prerequisites

Before testing begins, the written authorization document, asset inventory, and ownership verification are completed. If third-party infrastructure is present, an additional authorization chain is prepared; otherwise, the relevant asset remains out of scope.

• A client-signed statement of work (SoW) and RoE appendix are ready.
• Ownership of the IP, domain, SSID, and segment inventory is documented.
• An additional authorization process has been opened for third-party infrastructure.

2 - Providing access

The access list differs by module. External Network is executed remotely, so an IP and domain list suffices; Internal Network requires a gray-box account model together with VPN or jumpbox infrastructure; the Wi-Fi module does not start without on-site access and a location list.

External Network access list

• Internet-facing IP blocks and specific edge IP addresses.
• Domain and subdomain list (for hybrid scope, if applicable).
• VPN gateway, reverse proxy, and WAF or CDN edge layer details.

Internal Network access list

• A VPN or jumpbox access account; the required privilege level is defined.
• Active Directory or Entra ID directory structure and segment map.
• Critical service inventory and account model (gray-box account attributes).

Wi-Fi access list

• On-site access and location list (with timing and escort details).
• SSID list and VLAN mappings (corporate versus guest separation).
• Authentication type (WPA2, WPA3, 802.1X) and NAC configuration.

3 - Stakeholder list

The stakeholder list consists of four roles, each with a concrete owner on the client side. The escalation line covers these four people; if the test scope or the RoE document changes, the decision comes from this list.

• Network and infrastructure owner: scope, segments, access model.
• Identity owner: AD or Entra directory structure, account model, privilege policy.
• Security sponsor: RoE, approval gates, reporting preference.
• On-site contact (for the Wi-Fi module): site access, escort, location schedule.

4 - Deliverable preferences

Deliverable preferences are fixed before testing begins. The attack path narrative is the default for Package Level 2 and above; the reporting language is chosen as single or dual language; a request to add control mapping (ISO 27001, NIST CSF, KVKK, BDDK) is reflected in the scope price.

• Attack path and lateral movement narrative: preferred for Package Level 2 and above.
• Reporting language: single language or dual Turkish and English.
• Control mapping preference: ISO 27001, NIST CSF, KVKK, BDDK references.

5 - Schedule and test window

The test window is fixed together with the in-hours or after-hours choice, the production freeze calendar, and the client operations cadence. If expedited delivery is requested, the price multiplier is stated in the RoE appendix; if the production environment is highly sensitive, the window is narrowed.

• In-hours or after-hours preference and its rationale.
• Production freeze periods and the critical release calendar.
• Location visit schedule for the Wi-Fi module (including the on-site escort).

1 - Prerequisites

Authorization, ownership, and inventory are the three core prerequisites. A scope statement cannot be produced until all three are complete.

• Provider authorization and proof of ownership: which provider (AWS, Azure, GCP, or multi-cloud) and which legal entity the authorization runs through is established.
• Account, subscription, or project inventory: the list of AWS account IDs, Azure subscription IDs, or GCP project IDs is fixed in writing.
• The region list, landing zone architecture, control plane sharing (shared services account), and critical data definition are clarified in advance.

2 - Providing access

The access model starts with a read-only role; when attack path quality requires it, a controlled test role is added. Administrator-assisted access is optional.

• Test IAM role or principal: a cross-account read role and a limited test role for AWS, Reader, Security Reader, and a limited custom role for Azure, Viewer and a limited custom role for GCP.
• Log read access: read permission for AWS CloudTrail, Azure Activity Log, and Cloud Audit Logs is granted from the outset for traceability; loss of visibility is a cause for escalation.
• Hierarchy scope: the AWS Organizations, Azure Management Group, and GCP folder structure is taken into account; scope does not accidentally drift under the root account.
• MFA, VPN, bastion host, PIM, and JIT constraints are part of the access model; they are clarified before the proposal and the test window is aligned to them.

3 - Stakeholder map

There are four stakeholders: cloud platform, IAM, security, and billing. All four are part of the authorization document and the test window confirmation chain.

• Cloud platform owner (SRE, DevOps, or platform engineering): confirms the scope decision and the architecture topology.
• IAM and directory administrator (AWS IAM, Microsoft Entra, GCP IAM): manages test role creation, privilege assignment, and revocation.
• Security team (CISO, SecOps): the decision authority for RoE, escalation, and approval gates; oversees the monitoring stream.
• Billing contact: coordinates immediately on any signal of unusual resource consumption; receives the post-test cleanup records.

4 - Deliverable preferences

Deliverable preferences are chosen in advance at the level of control mapping and additional evidence format, and the reporting effort is reflected in the proposal.

• Control mapping: which of the CIS AWS, Azure, or GCP Foundations Benchmarks, NIST CSF 2.0, NIST SP 800-53, SOC 2, or Microsoft Cloud Security Benchmark references will be mapped is chosen in advance.
• If a customer security review (FedRAMP, SOC 2, ISO 27001, BDDK, KVKK) is a priority, the control mapping summary is handed off to a portable trust layer.
• The executive summary, technical findings report, reproduction steps, attack surface inventory, and prioritized remediation list come with the standard package.
• The attack path diagram, board-level risk summary, and workshop are add-ons dependent on the package level.

5 - Schedule

The schedule is built taking into account production traffic peak windows, the release calendar, and customer security review dates.

• Production traffic peaks (campaign windows, month-end close, release trains) are moved outside the test window; the rollback line is defined in advance.
• The typical duration is 2 to 4 weeks; scope, access quality, and the test window determine the duration.
• Expedited delivery (10 business days or fewer, 5 business days or fewer) keeps the scope narrow; the manual verification line is shortened from the outset.
• The retest and quarterly re-verification logic is written into the schedule from the outset; a discounted retest can be taken within 45 days on the same scope and same architecture.

1 - Prerequisites

The triple written approval of Human Resources, Legal, and Information Security is completed. The KVKK disclosure obligation, employee data minimization, and the disclosure approach (the balance between prior explicit disclosure and preserving campaign integrity) are fixed in writing. The campaign does not go live until the approval chain is complete.

• Written approval from HR, Legal, and Information Security.
• Review of the KVKK disclosure obligation.
• Employee data minimization is fixed in writing.

2 - Providing access

The target employee list (broken down by segment and persona), the reporting channel (report-phish button, email, phone), and the set of controls to be verified (email gateway, MFA, response platform) are defined. If access inputs are missing, the measurement baseline cannot be established.

• Target employee list: broken down by segment and persona.
• Reporting channel: channel capacity and escalation chain.
• Control set definition: the technical controls to be measured.

3 - Stakeholder map

Human Resources, Information Security, internal communications, the detect-and-report and response team (SOC or help desk), and a senior management representative are on the stakeholder list. Each stakeholder's role, communication channel, and campaign-notification timing is clarified in writing.

• HR and internal communications: managing the impact on employees.
• Detect-and-report and response team: channel flow verification.
• Senior management: the executive summary and closeout summary meeting.

4 - Deliverable preferences

The reporting preference is anonymized and aggregate. Personal names, user IDs, or individual record details are kept out of the report; the segment, persona, and wave breakdown is preserved. Individual reporting is not the canonical preference; exceptional cases are evaluated through a separate approval gate.

• Canonical: anonymized aggregate reporting.
• Individual reporting is not the default; separate approval is required.
• Breakdown: segment, persona, and wave.

5 - Schedule and period check

The campaign schedule avoids peak periods. Fiscal year-end close, religious holidays, public holidays, crisis-communication periods, layoffs, and merger or acquisition processes are automatically out of scope. The schedule decision is settled with stakeholder approval; a surprise period change undermines campaign integrity.

• Fiscal year-end close is out of scope.
• Religious holidays and public holidays are out of scope.
• Crisis, layoff, and merger periods are out of scope.

1 - Prerequisites

The prerequisite check tests whether the program is the right service. Three questions are answered before the program goes live; lines that come back 'no' route to the right service.

• Is the release cadence sustainable for 3 months or more? Can a monthly or biweekly production release be committed to?
• Is the target asset defined as a web or API surface? Is a mobile, internal network, or cloud posture not the primary need?
• Is a single pre-release validation sufficient? If yes, proceed to the Application Security Penetration Test page.

2 - Providing access

A continuous access model is established throughout the program. What distinguishes it from a single-window project test is that the test account is validated live for every cadence, not just once; the OpenAPI and release-notification integration is connected to the program.

• Continuous access account: role-based test accounts are kept active for the duration of the program.
• The OpenAPI or Postman collection is synced live and kept current with every release.
• A release-notification integration (CI/CD or release notes feed) is opened to the test team.
• WAF, rate-limit, and operational constraints are shared with the test team; exception windows are defined at the start of the month.

3 - Stakeholder map

The close-and-verify cycle calls for a lean communication line. How the product, security, operations, and senior management owners connect to the program is clarified at the start of the month; each finding stays with a specific owner.

• Product team: the backlog owner; the remediation window and release planning run here.
• Security team: the owner of finding validation, risk prioritization, and re-verification approval.
• Operations team: WAF, rate-limit, and test window coordination.
• Senior management: the monthly executive summary and quarterly trend reading; the decision support line.

4 - Deliverable preferences

Program deliverables are not limited to the technical report; the management dashboard, trend chart, and end-of-cadence report format are recorded as preferences at the start of the month. If a dual-language need (TR/EN) exists, it is defined as an add-on.

• Management dashboard: a tracking view of remediation rate, MTTR, and risk trend.
• End-of-cadence report: executive summary, technical backlog, remediation evidence.
• Dual-language output (TR and EN): defined as an add-on if a customer security review is required.
• Export to Jira or an issue-tracking space is planned according to the package level and add-on.

5 - Cadence schedule

The monthly cadence schedule is positioned around release-freeze days and critical workflows. The choice of start, mid, or end of month is made according to the release tempo and the customer security review calendar; once chosen, it is kept fixed for three months.

• Cadence choice: start, mid, or end of month; outside the release-freeze day.
• Alignment with the release freeze: the test window is shifted during critical periods.
• The right to validate an off-cadence release is planned as an add-on according to the package level.

1 - Prerequisites

The Modular Red Team Simulation does not begin without written senior management approval, a designated white team set, and a defensive maturity self-assessment. The blue team is not informed; this is mandatory so that true detection capability can be measured. In an environment with weak defensive maturity, penetration testing may take priority over Red Team; that decision is made at this table.

• Senior management approval (CISO or CTO; CEO awareness in critical scenarios) is fixed in a written document.
• White team designation: 2 to 4 people; CISO, security director, senior management contact, legal.
• Blue team non-disclosure: mandatory for measuring true detection capability.
• Defensive maturity self-assessment: the SOC, EDR, SIEM coverage and runbook maturity are reviewed.

2 - Access and initial foothold

The scenario's initial foothold varies by core module. In the RT-1 threat-actor scenario, a realistic initial vector matching the attacker profile is fixed; in the RT-2 objective-focused scenario, a black-box, gray-box, or assisted start is preferred; and in the RT-3 assumed-breach scenario, the assumed starting point where the attacker has already reached the internal network (for example a compromised user identity or endpoint) is defined in writing. For RT-4A, the social engineering channel and target persona set are fixed.

• RT-1 start: an external vector matching the threat actor (aligned with the attacker type).
• RT-2 start: black-box, gray-box, or assisted; chosen according to the crown jewel objective.
• RT-3 start: the assumed breach point (user identity, endpoint, identity token) is written down.
• RT-4A start: the target persona set, channel (email, SMS, voice, QR), and approval of the message copy.

3 - Stakeholder matrix

The white team is kept narrow. A typical grouping: CISO or security director (authorization holder), a senior management contact (escalation line), the critical infrastructure owner (asset verifier), and legal counsel (authority and data boundary). The blue team (SOC, MSSP, IR team) is not informed and remains outside the engagement scope. If there is a third-party service provider, the authorization chain is tied to a separate contractual clause.

4 - Deliverable preferences

Deliverable preferences are settled before the engagement begins: executive summary language (Turkish or English), attack path timeline format, MITRE ATT&CK technique mapping detail, MITRE D3FEND control recommendation depth, and the purple team workshop option (as lightweight in-package validation in RT-5 or as a separate sprint). These preferences determine how quickly the evidence package turns into a decision at the investment table.

• Executive summary language preference: Turkish or English, with a dual-language option.
• The detection gap matrix is mapped at the MITRE ATT&CK technique level.
• The chain-breaking control recommendation is mapped to the MITRE D3FEND defensive technique catalog.
• Purple team workshop option (lightweight in-package validation or a separate RT-5 sprint).

5 - Schedule and window

The engagement duration is typically 2 to 6 weeks depending on scenario complexity; engagements tied to a regulated framework (TIBER-EU, CBEST) take longer. During preparation, the organization's major release windows, year-end close, holiday and public holiday periods, and audit calendars are checked for conflicts. The ethical boundary windows are fixed in the RoE document.

1 - Prerequisites

The prerequisites cover written authorization, completion of the agent inventory, verification of the third-party model provider's terms of use, and readiness of a sandbox or canary tenant environment. A missing prerequisite leads to scope and schedule slippage.

• Written verification of agent or account ownership via a signed statement of work (SoW).
• Agent workflow inventory: agent name, business purpose, tool count, RAG source family, MCP server, role profile.
• Preliminary review of the third-party model provider acceptable use policy (AUP) and a compliant test profile.
• Sandbox or canary tenant environment: synthetic data, isolated connectors, test accounts.

2 - Providing access

The access the test team needs is provided before the test window. The system prompt, tool catalog, a sample of the RAG vector database content, the MCP server list, and log read access are granted under a written least-privilege principle.

• Read access to the system prompt and the safe execution boundary definitions.
• Tool registry: tool name, description, parameters, authorization scope, permission matrix.
• RAG vector database and a representative content sample (anonymized or synthetic).
• MCP server list: authorization method, scope, token flow, session management.
• Log read access: agent behavior, tool call records, error traces, and the event logs that trigger a breach.
• VPN or IP allowlist, MFA, and the test account lifecycle definition.

3 - Stakeholder table

The right stakeholder table keeps the scope realistic. The AI product lead, ML or platform engineer, security sponsor, legal counsel, and senior management contact sit at the table as owners of scope and decision impact.

• AI product lead or agent workflow owner: the scope approval and decision impact side.
• ML or platform engineer: the technical representative for the tool, RAG, MCP, and system prompt side.
• Security sponsor: the side for the RoE signature and controlled testing discipline.
• Legal counsel: model provider terms of use, data processing, and the escalation line.
• Senior management contact: the recipient of the executive summary and the management side of decision impact.

4 - Deliverable preferences

When the output format is clarified before discovery, report reading time and decision speed improve. The chain package format, framework mappings, and the presentation of chain-breaking control recommendations are put in writing.

• Chain package format: a visible sequence of the prompt, tool, data, and privilege links.
• Framework mapping: OWASP Top 10 for LLM Applications 2025, MITRE ATLAS, and NIST AI RMF categories.
• Chain-breaking control recommendations: system prompt, tool permission, RAG access, MCP approval, output filter.
• If a dual-language reporting need (TR and EN) exists, it is determined from the outset.

5 - Schedule

The test window is not overlapped with release periods or model provider update calendars. The preparation phase covers scope and access verification, the test phase covers execution, and the reporting phase covers the acceptance and retest gate.

• Typical duration 2 to 4 weeks; typical effort 8 to 14 person-days; flexible under manual scoping.
• Model provider update periods and release windows are reviewed.
• If there will be a production touch, a narrow window and freeze periods are written down.

1 - Prerequisites

The model owner's written authorization is a prerequisite. The model inventory (production and staging), version list, and owner are prepared in a defined form; a start without an inventory triggers the manual scoping flag.

If a third-party foundation model is used, the provider list (Hugging Face, OpenAI fine-tuning, closed provider) and the terms of use document must be ready. License interpretation is outside the service scope; it is handled only at a flag-marker level.

2 - Providing access

The access rings are tiered according to the evidence mode. The primary ring is model registry read, CI/CD pipeline read, and attestation log read. The secondary ring is sample access to the training data inventory and deployment manifest read.

The access-provisioning teams are defined on the ML platform side from the outset; the role matrix and time threshold are aligned with the written authorization. In air-gapped or regulated environments, an on-site work window is opened.

3 - Stakeholder layout

Multiple stakeholders are at the table: ML platform (model owner and MLOps), security (sponsor and technical contact), data or governance (training data management), and legal (KVKK, regulation, licensing). A missing stakeholder halts the engagement.

If special-category personal data under KVKK is present, the data controller's representative is added to the approval chain. The management-level sponsor is defined from the outset as the top link of the escalation line.

4 - Deliverable preferences

The expected evidence deliverables are listed from the outset: an ML-BOM in CycloneDX format, an SLSA level assessment, a registry signature audit report, an attestation gap analysis, and a hardening backlog. The format preference is chosen according to the audit and customer review surface.

The evidence mode has three options: internal assurance, an audit-ready evidence package, or a board-ready package. The choice of deliverable preference directly determines the package level and the scope of the evidence appendix.

5 - Schedule

The engagement schedule is planned so as not to overlap with the retraining, fine-tune, and release waves of the MLOps calendar. The typical duration is 2 to 3 weeks; the expedited delivery option depends on the evidence mode and access maturity.

The emergency communication channel, response threshold, and escalation stakeholder are written down from the outset. Holiday periods and release freeze windows are marked as flags in the schedule conflict check.

1 - Prerequisites

The internal pilot of AI for Penetration Testing and Red Team does not begin without a written commitment from the internal offensive lead, 1 or 2 priority use cases, and a selected AI vendor. Vendor selection is not just a technical choice; the acceptable use policy, data processing terms, and enterprise contract basis are evaluated together. Setting out with an immature list of use cases puts the pilot output at risk; that decision is made at this table.

• The internal offensive lead's commitment (P12) is fixed in a written document; the pilot owner is clear.
• Use case prioritization: 1 or 2 scenarios at the start; each with an owner and acceptance criteria.
• AI vendor selection: the model AUP, DPA, and enterprise contract basis are verified.
• The expectation of a 'fully autonomous attack agent setup' is rejected; the pilot is human-supervised.

2 - Access and eval set data inventory

The eval set data is inventoried before the actual pilot begins: an anonymized set of prior reports, screenshot and log samples, an anonymized PoC archive, and a finding-pattern library. The sandbox pipeline is set up by the internal team; real customer data is not fed into the model as training input. The observability platform (LangSmith, Phoenix, or equivalent) is configured to carry logging, audit trail, and rollback criteria; the privacy policy is written to be KVKK- and AUP-compliant.

• Eval set data inventory: reports, screenshots, logs, and PoCs anonymized.
• Sandbox pipeline: an isolated environment; no direct contact with production data.
• Observability platform: logging, audit trail, telemetry, and rollback.
• Privacy control: customer data is not fed into the model; opt-out is verified in writing.

3 - Stakeholder matrix

The internal pilot team structure is fixed in writing: the internal offensive lead (P12) is the owner and handover recipient of the pilot; a senior penetration testing or Red Team specialist is the authority on the final finding decision; the security team owns the observability design; legal counsel oversees AUP, DPA, and KVKK compliance; the product or IT owner owns access and operation of the sandbox infrastructure. The pilot handover recipient is determined from the outset; when the pilot is accepted, the workflow is handed over to this person in writing.

• Internal offensive lead (P12): pilot owner and handover recipient.
• Senior penetration testing or Red Team specialist: the authority on the final finding decision; the expert approval gate.
• Security team: the owner of the observability design.
• Legal counsel: AUP, DPA, KVKK, and data processing compliance.
• Product or IT owner: sandbox infrastructure access and operation.

4 - Deliverable preferences

Deliverable preferences are settled before the pilot begins: the workflow design document (at the use case unit level), the eval set structure (acceptance ranges and stop thresholds), the controlled pilot report format (executive summary and expert analyst layer), and the observability dashboard design (logging, audit trail, telemetry, and rollback fields). These preferences determine how quickly the internal team evaluates the pilot at the acceptance gate.

• Workflow design document: at the use case unit level.
• Eval set: acceptance ranges and stop thresholds are written down.
• Pilot report format: executive summary and expert analyst layer (dual-layer delivery).
• Observability dashboard: logging, audit trail, telemetry, and rollback fields.

5 - Schedule and window

The pilot duration is typically 4 to 8 weeks depending on complexity; the handover cycle is completed within 1 to 2 weeks after pilot acceptance. During preparation, the organization's major release windows, the customer delivery calendar, and the audit and regulation calendar are checked for conflicts. The pilot is not overlapped with a schedule that would create a stop risk in the real customer delivery flow.