How to Prepare for a Penetration Test: A Crypto Checklist

Video transcript

Testers can only test what they can reach. A missing account, a broken staging build or an unsigned scope can each eat into days you paid for.

Start with scope, written down by name: domains and APIs, cloud accounts, repositories, and the chains and offchain services that sign. Then sign rules of engagement.

Create test accounts for every role. Cover each KYC tier, two accounts per role, admin roles, API keys at each permission level, and 2FA seeds.

Pentesters never need your private keys. Use testnet funds or a local mainnet fork, and a staging signer on test keys, so withdrawals run end to end without moving anything real.

Next, pick environments. Keep signing and withdrawals in staging, test exposed services in production with care, and prove onchain impact on a fork. Then freeze the build.

Brief your security team and list tester IP addresses, so they can tell testing from a real attack. Allowlisting a rate limiter saves time, but leaves that control untested. Record the choice.

Hold a kickoff on architecture and money flows. Agree daily check-ins, name who hears about Criticals, and keep an engineer on call.

The report starts the work. Triage with code owners, find the root cause, test fixes outside production, assign owners and dates, then retest.

Guardian's pentests cover web apps, APIs, cloud and SDKs. Read the full checklist below, or book a system review at guardian.security.

Testers can only test what they can reach. A missing account, a broken staging build or an unsigned scope can each eat into days you paid for.

Crypto teams have extra work: test funds, signing services, and keys that must never leave your hands.

This checklist covers it in order. For contracts, see how to prepare for a smart contract audit.

Scope and Rules of Engagement

Start with what will be tested, and what will not. PTES says all targets must be identified before a penetration test starts.

Write the scope down by name:

• Domains, apps and API base URLs.
• Cloud accounts, and the services inside them.
• Repositories, and the commit or release under test.
• Chains, contract addresses and the offchain services that sign.

Vendors need their own sign-off. PTES notes that a client does not speak for its third-party providers.

Decide how much testers see. PTES says a full or partial white-box test may bring more value than a black-box test.

So share source code, API specs and architecture diagrams where you can. Give repository access at GitHub's Read role, the lowest of its five repository roles.

Then sign rules of engagement. Our rules of engagement template covers every clause, from stop conditions to cloud provider rules.

Accounts, Keys and Test Funds

Testers need to act as every kind of user. Create test accounts for each role:

• A new user and a fully verified user, at each KYC tier you run.
• Two accounts per role, so testers can try to reach each other's data.
• Admin, support and operations roles, if the back office is in scope.
• API keys at each permission level, including read-only.
• 2FA seeds or devices, so testers can reach protected actions.

Label every test account clearly. Disable them all after the retest.

Test funds

Fund test accounts with testnet tokens or a local fork, not real money. Ethereum.org names Sepolia the recommended default testnet for application development.

To prove onchain impact, testers can fork mainnet at a specific block with Foundry's Anvil.

Signing services and keys

Point testers at a staging signing service that holds test keys. Withdrawals can then run end to end without moving anything real.

Production keys, seeds and signer devices stay out of reach. Your rules of engagement say what happens if testers find key material.

Environments and Monitoring

Next, decide where testing happens. NIST SP 800-115 lists three factors: the impact on production, exposure of personal data, and how closely a copy matches production.

Its advice: run techniques likely to cause a denial of service against non-production systems, and use test data instead of real personal data.

The catch, NIST adds, is that test and production environments usually differ. Those differences can hide vulnerabilities.

One workable split:

Seed staging with realistic fake data: users, balances, open orders and withdrawal history.

Freeze the build under test. Code that changes mid-test was not tested.

Monitoring and allowlists

Tell your security team the test is coming. NIST says tester IP addresses belong in the plan, so administrators can tell testing from a real attack.

Then decide on allowlisting. NIST notes administrators can set intrusion detection to ignore tester IPs, if that suits the test's goals.

Allowlisting a firewall or rate limiter saves testing time, but leaves that control untested. Record the choice in the rules of engagement.

Keep logging on. Afterwards, check which test activity your alerts caught.

Communication During Testing

Hold a kickoff before day one. Walk testers through the architecture, the money flows and the parts you trust least.

Agree a channel and a rhythm. PTES recommends short daily meetings on three things: plans, progress and problems.

NIST's example for a one-month pentest is weekly status meetings, with daily reports during active testing.

Agree how Criticals reach you mid-test. NIST says people such as the CIO, CISO and ISSO should hear of critical, high-impact vulnerabilities as soon as they are found.

Share an emergency contact list. PTES says sensitive communications, especially the final report, must be encrypted.

Keep an engineer on call to unblock testers the same day.

What to Do With Results

The report starts the work. NIST says a test is much more valuable when it produces a mitigation strategy that gets implemented.

1. Triage: review each finding with the engineers who own the code.
2. Surprises first: NCSC says vulnerabilities you did not know about deserve special attention.
3. Root cause: NIST asks for root cause analysis in each recommendation.
4. Safe rollout: NIST advises testing each fix on a non-production system first.
5. Owners and dates: NIST calls for a plan of action and milestones, with specific, measurable actions.
6. Retest: NIST notes testers can verify a fix only by repeating the original test.

The fixes are your call. NCSC says testers' proposed solutions may not be the only ones, and decisions on fixes are yours.

Then report up. See our pentest executive summary example.

Readiness Checklist

Before day one, confirm:

• Scope written by name, with an exclude list.
• Vendor and cloud permissions obtained in writing.
• Rules of engagement signed.
• Source, API specs and diagrams shared read-only.
• Test accounts for every role, with 2FA and API keys.
• Testnet funds or a mainnet fork ready.
• Staging signer on test keys; production keys out of reach.
• Build frozen, staging seeded with fake data.
• Security team briefed, tester IPs listed, logging on.
• Kickoff booked, channel and emergency contacts shared.
• Fix owners named and the retest booked.

For the calendar around all this, see how long a pentest takes.

How Guardian Runs Pentests

Guardian's pentests cover web apps, APIs, cloud and SDKs, tested by your contract auditors for exploitable paths to funds.

Each engagement is scoped by what it tests:

Not sure what belongs in scope? Book a system review: an hour with a Guardian engineer on what you actually run.

Frequently Asked Questions

What should we give pentesters before testing?

Signed rules of engagement and a scope written by name. Then test accounts for every role with 2FA and API keys, source and API specs where possible, a production-like environment, and named contacts for Criticals.

Should a pentest run in production or staging?

Often both. NIST SP 800-115 suggests non-production systems for disruptive techniques and personal data, but warns test environments usually differ from production. Keep signing and withdrawals in staging, on test keys.

Should we tell our security team about a pentest?

Usually, yes. NIST says tester IP addresses should be listed so administrators can tell testing from real attacks. To test how staff respond instead, NIST describes covert testing: upper management approves, IT staff are not told.

Do pentesters need our private keys?

No. Give testers test keys on a staging signing service, plus testnet funds or a mainnet fork. Production keys, seeds and signer devices stay out of scope.

Sources

• NIST: SP 800-115, Technical Guide to Information Security Testing and Assessment (September 2008)
• PTES: Pre-engagement Interactions (mirror of pentest-standard.org)
• NCSC: Penetration testing (published August 8, 2017; reviewed January 10, 2022)
• GitHub Docs: Repository roles for an organization (accessed November 6, 2026)
• ethereum.org: Networks (updated September 23, 2026)
• Foundry: Anvil overview (accessed November 6, 2026)
• Guardian: Penetration Testing
• Guardian: System review