Standards can be difficult to comprehend and to implement in practice. This is due to many factors, such as the generic nature of standards in using concepts and vocabulary of any particular context and also the specific nature of the standards, which makes them refer to and acknowledge only the issues that they have been authorised to tackle – the idea being that there are other standards for other issues. Safety-related standards can thus be difficult to grasp and the IEC 61508 series is no exception. While one expert in a company may have the time and capability to fully understand the standard, it needs to be communicated to others so that it is practiced in projects and other day-to-day activities. Some external help is clearly required. Training is one route, and even it needs more understandable descriptions so as to communicate the issues. A process pattern is a concept that aims to present important aspects of an activity with a modular expression that can become familiar to personnel. In fact, the pattern descriptions highly resemble the description used in many companies, such as: • Process description cards used as instructions. • Templates of use cases used in software development. Therefore, in the Ohjelmaturva project we have done research on the use of safety process patterns to help in utilising the IEC 61508 standard series (2nd edition) and especially its third part (IEC 561508-3 2nd ed.) which concerns software development. This report presents a) some ideas behind the patterns aiming to give guidance to future pattern developers and b) a preliminary pattern collection. The patterns presented in this reports do not form a complete collection of all necessary patters, nor do they cover all aspects of the standards, but present a view to the standards that in our opinion does not have conflicts with the standards and can greatly aid in their understanding and utilisation. Note that this report mostly addresses issues of the traditional V-model based development. For an analysis of how the standards' requirements could be fulfilled in an agile development process, see the sister publication to this report, "Agile Development of Safety-Critical Software" (Vuori, 2011).