Podczas planowania testów zabezpieczeń należy w szczególności zastanowić się nad następującymi zagadnieniami:

• Ponieważ problemy dotyczące zabezpieczeń mogą się pojawić w trakcie tworzenia architektury, projektowania i implementacji systemu, można zaplanować testy zabezpieczeń na poziomie testowania jednostkowego, integracyjnego i systemowego. Ze względu na zmienność zagrożeń, testy zabezpieczeń można także wykonywać regularnie po wdrożeniu produkcyjnym systemu.

• Strategie testów zaproponowane przez technicznego analityka testowego mogą obejmować przeglądy kodu i analizę statyczną z wykorzystaniem narzędzi do zabezpieczeń. Narzędzia tego typu mogą być skutecznym środkiem wykrywania problemów związanych z bezpieczeństwem w architekturze, dokumentach projektowych i kodzie, które łatwo pominąć w trakcie testowania dynamicznego.

• Techniczny analityk testowy może zostać poproszony o zaprojektowanie i wykonanie pewnych typów „ataków” (patrz poniżej), które wymagają szczegółowego zaplanowania i skoordynowania działań z interesariuszami. Inne testy zabezpieczeń można wykonać we współpracy z programistami lub analitykami testowymi (np. testowanie praw użytkowników, zasad dostępu i uprawnień). W ramach planowania testów zabezpieczeń należy szczegółowo uwzględnić kwestie organizacyjne tego rodzaju.

• Kluczowym aspektem planowania testów zabezpieczeń jest uzyskanie akceptacji działań. Techniczny analityk testowy musi uzyskać wyraźne zezwolenie od kierownika testów na wykonanie zaplanowanych testów zabezpieczeń. Wszelkie dodatkowe, niezaplanowane testy mogą zostać uznane za rzeczywiste ataki, a osoba wykonująca takie testy jest narażona na podjęcie wobec niej działań prawnych. W przypadku braku potwierdzenia planów i uzyskania akceptacji w formie pisemnej wytłumaczenie typu „my tylko prowadzimy testy zabezpieczeń” może nie zabrzmieć zbyt przekonująco.

• Należy zwrócić uwagę, że udoskonalenia, których celem jest poprawa bezpieczeństwa systemu, mogą obniżyć jego wydajność. Po wprowadzeniu takich modyfikacji zalecane jest rozważenie konieczności wykonania testów wydajnościowych (patrz punkt 4.5 poniżej).