There's nothing about this problem that's specific to SPI.
Any receiving device will require a certain amount of set-up time before an active clock edge, and hold time after it. Those timings will be specified in the device's data sheet, usually in a way that's nowhere near as clear as it could be.
Usually with SPI, data is made to change on one edge, and is then sampled on the other. This alleviates the need to worry too much about the precise relationship between clock and data, provided the interface isn't running too fast. As long as [(half a clock) - (propagation delays)] > (setup time), and similarly for hold time, you can get away without doing a static timing analysis.
Paradoxically, this approach does limit the maximum speed at which the interface can run. For a given pair of devices, and if there's a choice of what edge to use for what, having data sampled on the same edge on which it's updated can be quicker. This is because the receiver gets almost a whole clock's worth of setup time, and often the hold time requirement is (or is close to) zero, so the fact that the data becomes invalid just at the time of an active clock edge isn't a problem.
In this case, though, you absolutely do need to study the setup & hold requirements of the receiver, and the clock-to-out and other parameters of the driver, in order to ensure they're compatible. You may need to include your own PCB routing delays too.
Timing analysis is something which rarely seems to get a mention on the forums these days, probably because if you're just using a microcontroller to wiggle LEDs on and off then it's something you get away without having to do... but it's an absolutely fundamental part of digital circuit design, and about as much fun as grabbing the hot end of a soldering iron, IMHO.