The slave design is free to do either.
A slave can use the incoming SPI_SCK to clock its internal data shift registers that connect to SPI_MOSI and SPI_MISO. This simplifies the slave circuit as it doesn't require a local oscillator or separate clock source. The disadvantage is that it can only have simplistic behaviour when SPI_SCK is inactive between transfers or of bad quality/broken. This may not matter in many applications.
Or a slave can treat SPI_SCK as a bus state indicator and oversample it using a faster local logic clock, to identify its rising and falling edges. However, there has to be quite a high ratio between the local clock and the incoming SPI_SCK, at least 2:1 but preferably 4:1 or more. This may be prohibitive in designs with a high SPI_SCK frequency. When used, the slave have more complicated behaviour for error handling etc. and avoid any more internal clock domain crossing.
There is more to it than I've summarised here but that's the essence of it. I've nearly always used the latter method and oversampled SPI_SCK. It's been very reliable but I've had the luxury of FPGA/CPLD applications with the available gates, a fast local clock and a much slower SPI_SCK.
You can get an idea of how an IC is doing it from the timing specs' in the data sheet. If it states the maximum SPI_SCK frequency in relation to the local clock frequency, it may be oversampling SPI_SCK and using the local clock. Of course, there may be another reason it's stated that way, such as the local-clocked circuitry having to serve up or store data for the SPI_SCK'd serial interface circuitry. But it may be clear and it may well just tell you in the data sheet text anyway.